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 pointent 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, faces intérieures invisibles et faces 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 :

1. Le transport des données, qui sont échangées entre le moteur physique et les autres composants du système, et
2. 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

Origine et évolution du maillage de l'avatar Ruth

• Le maillage de l'avatar Ruth dans les viewers est encore un autre format de maillage Linden Lab qui n'a rien à voir avec le format de maillage dans le monde. C'est peut-être une licence de Poser (Ndrl : j'ai toujours entendu dire que Ruth était basé sur un avatar de Poser 5].
• Il a plus de fonctionnalités comme les cibles de morphing
• Les participants à la réunion pensent que le passage à l'utilisation de maillages pour les avatars est une erreur de Linden Lab. Il aurait fallu améliorer le modèle du système à la place, avec la carte UV originale pour la compatibilité ascendante, en plus d'une nouvelle carte UV. D'autant plus que la plupart des avatars en mesh ont beaucoup moins de possibilités de se transformer que l'avatar du système

Bento et Ruth 2.0

• Évolution du modèle d'avatar du système :

1. Bento a ajouté des os supplémentaires
2. Petite correction de quelques triangles mal alignés au début.

• Mais, Linden Lab n'a jamais pris la peine d'améliorer le maillage de base. C'est à ce moment qu'ils auraient dû mettre à jour le maillage de l'avatar pour que l'avatar système puisse bouger les doigts, ce qui est impossible sur le mesh original de l'avatar. Ils auraient pu simplement ajouter une version V2 à sélectionner dans l'apparence.
• Un groupe de personnes a essayé d'améliorer le maillage de l'avatar du système en créant Ruth 2.0. Ils ont essayé d'améliorer le maillage livré avec le viewer. Mais, ce n'est pas si facile, parce que les importateurs pour ce format ne sont pas très bons. Cela semble ne pas vraiment marcher. Ils n'ont jamais ajouté les transformations et les poids nécessaires. Au final, ce n'est pas vraiment différent des autres avatars en mesh. Ubit Umarov suppose qu'un convertisseur direct vers le format Blender était nécessaire, car Collada est tout simplement inadapté. Il aurait aussi fallu supporter les cibles de morphes dans l'éditeur de silhouette.

Linden Lab fait fonctionner le marché

• Linden Lab n'a jamais vraiment amélioré l'avatar système.
• Le choix des avatar en mesh pour améliorer l'apparence des avatar fait fonctionner le marché. Ils ont pu ainsi construire un marché sur des maillages tiers, ce qui rapporte beaucoup de dollars.

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.

Source

• http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2025-05-27