Réunion du 16-04-2024

Changements du code de la semaine

Quelques changements dans le code UDP

• Commit : [1]
• Création d'une table de saut pour chaque nouvel utilisateur :
  • Lorsque le programme doit effectuer un branchement conditionnel en fonction d'une valeur, il utilise l'index de la valeur dans la jump table pour accéder directement à l'adresse correspondante.
  • but : trouver le code pour gérer chaque type de paquet UDP.
• Nouveau dictionnaire : FrozenDictionary
  • Dictionnaire dotNet
  • Structure de données conçue pour stocker et accéder efficacement à un dictionnaire (une collection de paires clé-valeur) de manière immuable et en lecture seule.

Texture de terrain

• Correction d'un bug sur les changements de texture du terrain [2]. Les changements n'étaient pas envoyés aux autres personnes dans la région.

Connecteur MySQL d'Oracle

• Retour à l'ancien connecteur (déjà la semaine dernière).
• Le nouveau ne fonctionnait pas pour l'architecture ARM64 : Raspberry Pi et Orange Pi. Cela fonctionne pour Apple. Tous les processeurs de la série Apple sont des Arm64, avec leurs propres instructions ajoutées.
• Avec le nouveau connecteur il y aurait un peu moins d'utilisation de cpu et de mémoire mais, ce n'est pas flagrant.

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.😉

Noyau

PBR

• Avec PBR[3] sans un viewer compatible, on voit tous les terrains en gris. Ubit Umarov aimerait avoir une solution de repli. Mais, les viewers ne disent pas encore au simulateur qu'ils peuvent utiliser PBR pour le terrain. Faire cette supposition en se basant sur les chaînes de version, c'est s'exposer à des problèmes.
• Cette information pourrait être envoyées à la région au moment de la connexion, mais ce n'est pas le cas. Une autre solution serait d'envoyer une fausse capacité, mais cette information pourrait arriver trop tard.
• Précision : les objets PBR ont un nouveau format UDP et ils sont activés via une capacité, la région est informée. En revanche, les terrains envoient simplement les UUID des assets PBR à la place de ceux des textures, donc les anciens viewers (qui ne sont pas PBR compatibles) vont lire ces UUID comme ceux des textures et ne trouveront rien.
• S'il n'y a pas d'option de repli, la région doit être conçue pour le mode PBR ou le mode non PBR. Mais, beaucoup de monde ne pourra pas utiliser les nouveaux viewers. À l'heure actuelle , seules les personnes qui testent le viewer (alpha ?) de Second Life peuvent voir les terrains PBR.

Modules

Chat vocal WebRTC, Linden Lab publie des informations

• Le chat vocal WebRTC va probablement prendre beaucoup de temps pour être achevé.

Protocole

• Vincent Sylvester essaie de définir le protocole et toutes les parties pour former une sorte de plan d'attaque pour ce projet.

Janus WEBRTC

• Le serveur web Janus [4] est un serveur web open-source très utilisé pour le développement d'applications de communication en temps réel, comme des systèmes de visioconférence, de streaming, etc. Quelqu'un a informé Vincent Sylvester que le backend de l'application utilise le serveur web Janus et il a configuré son système pour intégrer et utiliser le serveur Janus dans OpenSim.
• Janus est simple à installer, mais d'après la documentation, Liden Lab utilise les canaux de données fournis par Janus et les traite avec un plugin personnalisé.

Publication d'informations

• Linden Lab (?) a publié beaucoup d'informations sur ce qu'ils utilisent, des liens utiles sur GitHub vers les différents outils. Mais les changements propres pour supporter le son 3D n'ont pas été publiés, seul ce qui est opensource l'a été. Certains codes côté serveur sont uniquement pour Linux. Ils ont ajouté des capacités[5] au serveur et en utilisent des anciennes.
• C'est une version de WebRTC propre à Liden Lab qui ne fonctionne que sur leur propre serveur. Les connexions de base à WebRTC sont normales, c'est tout ce qui suit qui est un peu en désordre.
• Il semble que ce soit le viewer qui reçoive le flux audio et place la voix en fonction des données de position. Malheureusement, certaines choses ne sont pas complètement documentées et il n'y a que des extraits, le reste est à deviner. Au moins, la plupart des éléments fournis permettent de faire une rétro-ingénierie sur ce qui n'est pas là. C'est le gestionnaire du canal de données qui est personnalisé et non ouvert.
• Les connexions vocales entre les régions ont changé. La documentation semble montrer que les serveurs de région communiquent avec les serveurs vocaux et que chaque région a au moins un serveur vocal pour la voice 3D des parcelles.
• Les parties client sont directement dans le viewer. Il semble qu'il y ait aussi d'autres données que le viewer récupère... quelque part dans les données de l'agent.

Problèmes

• Comment faire pour changer de canal et les distribuer sur le backend ?
• Henri Beauchamp a posté beaucoup de choses[6](attention lien Google) sur la liste de diffusion opensource Linden Lab [7].
• Entre la région, le serveur vocal potentiel et les clients, il faut déterminer ce qu'il faut faire pour obtenir la meilleure latence. Idéalement, il faudrait géolocaliser le serveur vocal le plus proche des clients, mais la région est aussi un "client". Mais, On ne peut pas l'évaluer de la même manière qu'un client, ce qui pose un problème.
• Il faut aussi trouver le code de transfert pour passer d'un serveur vocal à l'autre, ce qui n'est pas encore fait.

Divers

Problème de précision des grandes régions

• Vincent Sylvester a configuré plus de 120000 régions 16x16 et OpenSim ne s'est pas cassé. Il a utilisé 1200 simulateurs avec chacun 100 régions en désactivant des tas de modules. Il a fait cela pour tester le temps de rendu des cartes de région. Cela a pris 3 heures avec le nouveau système.
• Les grandes régions ont des problèmes de précision, la limite serait 4km de côté, raison similaire pour laquelle on ne peut pas reezer à plus de 4km d'altitude. C'est pourquoi les régions sont limitées à 4 km et c'est peut-être déjà trop selon Ubit Umarov. 1km (4x4) est un bon chiffre.
• Certains nombres réels ne peuvent pas être représentés de manière exacte en utilisant des nombres à virgule flottante, ce qui peut entraîner des erreurs d'arrondi et des approximations. Plus les régions sont grandes et plus des écarts liés à cette approximation sont importants. Quand on dépasse les 1500 mètres l'arrondi commence à avoir un effet sur la précision. C'est la décision d'arrondir vers le bas ou vers le haut qui cause l'instabilité. Mais les besoins de résolution d'OpenSim ne sont pas très élevés sauf peut-être pour les nanoprimes.

Explication par Ubit Umarov
- Les nombres à virgule comportent une partie fixe de 24 bits et un multiplicateur.
- La partie fixe permet d'avoir 6 chiffres décimaux :
  * proche de zéro, cela signifie par exemple une résolution de 6 micron. 
  * à 1 km de l'origine le multiplicateur est de 1000, donc cela fait une résolution de 1 mm. 

• Les objets peuvent se déplacer de manière imprécise. Cela peut se manifester par des mouvements inattendus ou des décalages dans la position des objets.
• L'effet est plus important au coin opposé à 0,0 dans une région.

Ndlr : sauf erreur de ma part, 16x16 devrait correspondre à une région de 16*256m de côté c'est à dire 4096 mètres, donc approximativement 4km.

Viewers

Firestorm viewer et PBR

• Changements dans l'éditeur (ndlr : de terrain ?) de la version de développement de Firestorm pour faciliter l'utilisation des 3 types de matériaux. Les utilisateurs feraient pression sur Firestorm pour que les développeurs produisent un viewer mobile qui pourrait avoir besoin du terrain PBR.
• Miroirs
• Importation complète d'une scène GLTF[8], c'est une interface comparable à celle de l'importation de fichier Collada. (Ndlr : je ne sais pas si cette interface existe déjà dans le viewer en développement ou si elle est planifiée.)
• Le problème de l'importation avec un viewer c'est qu'on ne peut pas trouver de format d'objets "prêts pour le jeu" sans avoir à les retoucher ou les convertir. Il semble que certains attendent que GLTF apporte une solution à cela mais, ce ne sera pas encore le cas.

Source

http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2024-04-30