Réunion du 30-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 de cette 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'architexture 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. Faire cette supposition en se basant sur les chaînes de version, c'est s'exposer à des problèmes.

Modules

Chat vocal WebRTC

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

Source

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