Réunion du 27-05-2025
Changements du code de la semaine
Bug d'upload de mesh
- Commit 41d1fd] : correction d'une ancienne faute de frappe concernant le nombre de côtés lors du téléchargement du mesh.
- Le mesh plantait dans certains cas à cause d'un mauvais index. Mais, cela fonctionnait dans la plupart des cas.
- Voir développement ci-dessous.
Correctif de fonction YEngine HasScript()
- Commit 85a927 : correctif sur la fonction YEngine HasScript().
Avertissement
| Attention : Ce résumé existe pour orienter vos recherches. Des erreurs d'interprétation ne sont pas à exclure. Pour plus de précisions, veuillez vous référer aux sources ou vous adresser directement aux développeurs d'OpenSimulator en assistant aux réunions du mardi ou sur le canal IRC. Je ne fais pas partie des développeurs, ne vous adressez pas à moi pour les joindre. Merci.😉 |
Meshes
Problème de normales double face
Les normales
- La normale d'une face dans un objet 3D est une ligne imaginaire qui sort perpendiculairement de cette face. On peut l'imaginer comme une flèche qui indique la direction dans laquelle la face "regarde".
-
Les normales pointes vers l'extérieur des faces. -
Les normale ne sortent pas des faces intérieures. -
Triangulation des faces du maillage. -
Maillage dans OpenSim avec les faces extérieures visibles. -
Maillage dans OpenSim, face intérieures invisible et face triangulaires.
Problème
- Les faces de certains triangles de meshs importés dans OpenSim sont visibles des deux côtés, alors qu'elles ne devraient l'être que du côté où pointe la normale.
Flèchette
- Vincent Sylvester explique qu'il a rencontré un problème lors de l'importation d'un modèle de fléchette dans OpenSimulator. Les faces des ailes de la fléchette sont visibles des deux côtés. Lors de l'importation, le système a essayé d'accéder aux informations du maillage pour chaque parties, mais il a trouvé que le maillage n'avait que 4 entrées au lieu de 7, ce qui a causé une erreur. L'importation a échoué et a bloqué le processus. Il a remarqué que le corps de la fléchette avait des face visibles uniquement vers l'extérieur, tandis que les ailes avaient des faces visibles des deux côtés. Cela a créé une confusion, car le modèle devrait être soit entièrement à simple face, soit entièrement à double face, bien que le format Collada permette de mélanger les deux. Après avoir forcé l'importation, il a constaté que le corps de la fléchette avait des faces internes, ce qui n'était pas présent dans le modèle original, ce qui pourrait être forcé par le viewer.
Discussion
- Auparavant, ce bug n'arrivait jamais. Il est apparu avec les viewers PBR.
- Il semble que cela soit dû à l'utilisation d'un mauvais index. En tout cas le changement devrait empêcher l'explosion.
- Ubit Umarov dit que les viewers normaux ne devraient pas rendre les faces "intérieures".
- Par exemple, DAZ 3D et Unity ont des moteurs graphiques qui peuvent afficher les deux côtés des faces des maillages, ce qui permet d'économiser des triangles.
- Le problème est simulaire avec la physique, BulletSim et Second Life prennent en compte l'intérieur et l'extérieur des objets pour les calculs de collision. UbODE ne prend que l'extérieur.(Ndrl : Cela peut être plus efficace en termes de performance, car il réduit la complexité des calculs nécessaires pour simuler les interactions.)
- La fléchette est un modèle provenant d'un catalogue. Il faudrait toujours charger un mesh dans Blender3D et l'exporter à nouveau pour lui imposer un standard, car [[Lexique_des_réunions#Collada |Collada] est un standard trop ouvert pour ne pas inclure des absurdités.
Mesh et ubODE
Présentation d'ubODE
- ubODE : moteur physique développé par Ubit Umarov pour OpenSimulator, basé sur le moteur physique ODE (Open Dynamics Engine). Il fait partie de OpenSim-libs.
- Il utilise sa propre représentation interne du maillage. Bullet utilise une représentation de maillage différente de celle d'ubODE. Apparemment le moteur physique de Linden Lab et Bullet sont assez similaires.
Caractéristiques
- Les normes d'ubODE concernent :
- Le transport des données, qui sont échangées entre le moteur physique et les autres composants du système, et
- Le stockage des données relatives à la physique.
- Les formats internes utilisés par ubODE sont spécifiquement conçus pour améliorer les performances.
- ubODE prépare et transmet au viewer les données physiques nécessaires, qui sont ensuite utilisées par OpenGL pour dessiner les objets.
- Ce moteur de physique est développé pour améliorer la vitesse des calculs de collisions.
- La gestion de l'importation des modèles 3D et des données physiques dans ubODE permet de supporter correctement les types de physique suivants : NONE (pas de physique), PRIM (formes de base) et CONVEX (maillages). Ce support présente des problèmes dans le moteur physique Bullet.
Collada dans les viewers
- Les viewers lisent simplement les fichiers Collada et les convertissent en un format de maillage Linden Lab.
- Le format Collada n'est pas utilisé côté région ; il n'est pertinent que côté viewer.
- Ubit Umarov suppose que le format DAE a été utilisé pour les modèles importés parce qu'en 2003, c'était le seul format libre. FBX n'était pas libre d'utilisation à l'époque. En 2007, au moment de la création d'OpenSim, cela devait toujours être le cas.
Avatars
Le mesh de l'avatar Ruth
- 🏗️
Bento et Ruth 2.0
- 🏗️
SL fait fonctionner le marché
- 🏗️
Viewers
Origine du code d'importation des meshes de Firestorm
Question
- Où Firestorm a-t-il trouvé son code d'importation des meshes et pourquoi cela fonctionne t-il aussi mal ?
Réponses
- Collada donne le code pour lire les fichiers dae.
- Firestorm utilise principalement le code de Linden Lab comme pour glTF.
- Linden Lab a utilisé des modèles faits dans Maya comme référence et a dû les faire passer par un convertisseur Adobe, ce qui a introduit des déviations pour la norme dae.
- Firestorm utilise essentiellement le code Linden Lab pour l'importation des mesh pur, mais pour la sauvegarde/exportation, ils utilisent plutôt leur propre code.