Réunion du 13-08-2024

Changements du code de la semaine

Modifications mineures

• Commit 236187 : une autre référence nulle, merci Tampa (Vincent Sylvester)
• Commit b0d006 : encore une faute de frappe, merci Tampa

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

Modules

Module de chat vocal

Problème 1 : trouver une solution pour Windows

• Il faut mettre en place une solution efficace pour les standalones et les quelques grilles installées sur des serveurs Windows. Une solution Linux seule n'est pas une bonne solution.
• Ubit Umarov a essayé d'utiliser WebRTC, mais il dit que cela a été un échec total. Impossible de compiler sur Windows et sur Cygwin. Certaines parties utilisent des API de bas niveau du noyau Linux que Cygwin n'a pas.
• Il est également difficile de compiler Coturn pour Windows.
• Et il semble que Docker ne fonctionne pas non plus sur Windows. Il existe une solution chinoise qui compile avec Cygwin mais qui aurait besoin de Docker.

Problème 2 : son spatial

• La partie du code qui prend en charge l'espace 3D est un code spécifique à Second Life que l'on ne peut pas trouver ailleurs.
• Second Life utilise Janus comme MCU . Ils ont un canal de données personnalisé qui doit aussi fonctionner pour se connecter et Vincent Sylvester n'a pas encore trouvé comment cela fonctionne.

Problème 3 : intégration du serveur vocal avec OpenSim

• Vincent Sylvester explique qu'idéalement, il est préférable de ne pas intégrer le serveur vocal directement à OpenSim. Il est plus judicieux de faire fonctionner ce serveur de manière externe, ce qui permet une meilleure localisation. De plus, gérer un serveur vocal derrière un NAT peut être complexe et n'est pas à la portée de tous les utilisateurs.
• Il est plus simple, et probablement aussi beaucoup plus performant avec une meilleure latence, d'avoir un VPS de qualité situé près des utilisateurs et d'y installer les services nécessaires.

NDLR  : Séparer le serveur vocal d'OpenSim permettrait d'améliorer la gestion, l'accessibilité et la performance du service vocal et d'OpenSim.

• Il reste le problème des standalone pour qui ce genre de solution est difficile à utiliser. Mais, Vincent sylvester trouve qu'il n'est pas possible d'intégrer tout dans OpenSim ni de s'attendre à ce que la configuration soit toujours simple. Dans certains domaines, cela n'est tout simplement pas réalisable et cela pourrait ne jamais l'être. Par exemple, avec WebRTC, il est nécessaire de prendre en compte le plugin de données personnalisées, le module OpenSim et l'interconnexion entre le plugin et OpenSim. Chercher une solution qui fonctionne partout semble être une mauvaise approche.

Problème 4 : Indépendance de la plateforme vs. qualité

• L'indépendance de la plateforme ne doit pas se faire au détriment de la qualité de la solution.
• Un serveur TURN derrière un NAT, expose le réseau à des risques de sécurité, cela nécessite l'ouverture d'une large plage de ports. Cependant, Ubit Umarov souligne que les standalones sont également derrière un NAT.
• Il est préférable de se concentrer sur les aspects que l'on peut améliorer et aider les utilisateurs à installer leurs propres solutions (VPS et serveur TURN), plutôt que d'accepter des solutions de moindre qualité qui fonctionnent mal sous Windows.
• D'après Ubit Umarov une solution pourraît utiliser un serveur externe (comme un serveur TURN ) pour aider à la négociation, c'est-à-dire pour initier la communication. Ensuite, les messages vocaux seraient échangés directement (P2P) via UDP entre les utilisateurs.

NDLR  : Cette solution permettrait d'assurer une meilleure confidentialité. En utilisant WebRTC, les messages échangés peuvent être chiffrés, ce qui renforce encore la sécurité des communications.

Informations complémentaires

NDLR  : Cygwin[1] est un environnement qui permet d'exécuter des applications et des outils de type Unix sur les systèmes d'exploitation Windows. Coturn [2] est une implémentation libre et gratuite des serveurs TURN et STUN. Le serveur TURN est un serveur et une passerelle de traversée NAT pour le trafic média de la VoIP. Serveur TURN est utilisé lorsque les connexions directes ne peuvent pas être établies (par exemple, en raison de restrictions de pare-feu). C'est comme un relais, permettant aux données audio et vidéo de passer par le serveur TURN, ce qui garantit que la communication peut toujours avoir lieu. WebRTC peut utiliser un serveur TURN comme partie de son infrastructure pour gérer les connexions. Docker[3] : Docker est un outil qui peut empaqueter une application et ses dépendances dans un conteneur isolé, qui pourra être exécuté sur n'importe quel serveur Janus[4] : serveur de communication WebRTC MCU (Multipoint Control Unit)[5] : logiciel informatique ou machine servant à établir simultanément plusieurs communications de visioconférence ou de VoIP. Un NAT, ou "Network Address Translation" (traduction d'adresses réseau), est une technique utilisée dans les réseaux informatiques pour permettre à plusieurs appareils d'accéder à Internet en utilisant une seule adresse IP publique. VPS[6] ou "Virtual Private Server" (serveur privé virtuel), est un type de service d'hébergement qui permet à un utilisateur de disposer d'un serveur virtuel dédié à ses besoins, tout en partageant les ressources d'un serveur physique avec d'autres utilisateurs.

• Dans Second Life la configuration de la voice pourrait encore évoluer. Certains utilisateurs se sont plaints que la prise en charge spatiale n'était pas très bonne.

Carte

Génération de carreaux de carte

• État du projet à la dernière réunion.
• Le système de parallélisation pour la génération des niveaux de zoom crée désormais les niveaux de zoom en générant un grand nombre de tuiles en parallèle. Ensuite, il combine les images résultantes dans une image plus large (image composite qui représente une zone plus étendue), ce qui est beaucoup plus rapide que d'ajouter chaque tuile individuellement à ces niveaux. Les images 2 à 6 représentent le processus de « copie de chaque tuile dans l'image », tandis que les images 7 à 11 illustrent le processus de « combinaison des tuiles précédentes dans l'image plus grande ». Cette méthode permet de réduire l'utilisation du processeur pour les niveaux les plus élevés et d'accélérer le traitement d'un facteur de 2 ou plus.
• Pour générer 5120 tuiles de niveau de zoom à partir de 13046 tuiles de carte, le temps nécessaire était de 52,44 secondes.
• Les anciennes routines sont conservées. Ainsi, lorsque le système détecte qu'une nouvelle région a des tuiles ajoutées, il les intègre simplement aux niveaux de zoom existants, ce qui est relativement léger en termes de ressources.

Mises à jour du chargeur TIFF

• Mise à jour du chargeur TIFF pour passer de 16 bits à 32 bits en virgule flottante. Cela devrait donc offrir un niveau de contrôle granulaire équivalent à celui de RAW32. Il reste à tout tester.
• Les routines 16 bits ont été conservées mais , elles seront probablement supprimées.
• Ces fichiers se chargent correctement dans GIMP et peuvent être visualisés directement. D'autres programmes ( par exemple la visionneuse d'image de Windows) semblent les convertir avec moins de précision ce qui entraîne des différences dans l'affichage.
• Le chargeur PNG est plus compliqué à mettre à jour car il existe différentes méthodes de compressions et il n'existe pas d'option pour décompresser. Donc cela reste en attente.

Découplage de la partie rendu de maptile du processus

• Découplage du moteur de rendu des maptiles du processus afin que la console ne se bloque plus pendant la génération des tuiles de carte.
• Avec Warp3D, cela peut prendre jusqu'à 20 minutes, et pendant ce temps, nous ne pouvons rien faire

NDLR  : Warp3DImageModule : alternative à MapImageModul, de meilleure qualité mais qui demande beaucoup plus de ressources.[7](voir également le fichier de configuration OpenSim.ini du serveur OpenSimulator.

Générateur de maptile et objets sous l'eau

• Il semble que le générateur de tuile de carte n'ignore pas les objets qui sont sous l'eau. Mais il y a des limites supérieures, il pourrait aussi y avoir des limites inférieures. Vincent Sylvester a une région avec une hauteur de terrain à 0. Dans le générateur de mapimage, ces éléments apparaissent toujours. Il n'a pas essayé warp3dImageModule. Il pense qu'avec warp3dImageModule, le terrain est rendu et l'eau au-dessus aussi, parce qu'on peut voir le terrain quand l'eau est peu profonde. warp3dImageModule est lent à cause des gros objets complexes. On peut l'aider en faisant des meshes plus simples ou en réduisant les textures, etc.
• Andrew Hellershanks évoque l'idée de pour une région aquatique où tous les objets sont en dessous du niveau de la mer, la recherche d'objet avec

  Z >= niveau de la mer

  serait un moyen simple de gagner du temps. Mais, cela pourrait ne pas fonctionner si un objet avec son centre juste en dessous du niveau de la mer et sortait de l'eau.

Divers

Tuile réservée

• Vincent Sylvester veut trouver une solution pour « réserver » (NDLR : afficher quelque chose à la place ?) les tuiles pour qu'elles n'aient pas l'air vides si une région est connectée.
• Actuellement, le système envoie une texture d'eau pour représenter la région, puis il génère les tuiles de carte plus tard. Cela signifie que l'utilisateur peut changer de moteur de rendu à tout moment sans avoir besoin de redémarrer le système. S'il n'aime pas l'image de la carte actuelle, il peut passer au module warp3dImageModule pour un rendu différent, et cela peut être fait instantanément, sans redémarrer le système.

Suppression des fichiers terrain_image

• Cette refonte du module de carte inclut la suppression des fichiers terrain_image qui seraient téléchargés. Au lieu de cela, ils sont enregistrés directement dans la scène, de sorte que lorsque le

viewer les demande, la région les fournit directement au lieu d'être un « proxy » du serveur d'assets.

Viewers

Dayturn

• Gavin Hird a publié une version beta de son viewer : les utilisateurs de Second Life semblent télécharger les versions Mac et Windows.
• Le viewer n'est pas près d'avoir les supports PBR ou même AIS3. Mais, les services sur Second Life fonctionnent toujours sans AIS3.

NDLR  : Gavin Hird a écrit PBS, je ne sais pas ce que cela pourrait représenter, j'imagine que c'est une faute de frappe et qu'il a voulu écrire PBR. AIS3 ou "Avatar Inventory Service 3"[8] : version du service qui gère l'inventaire des avatars dans Second Life, permettant une meilleure gestion des objets et des contenus que les utilisateurs possèdent.

• Le viewer OS Mac a bénéficié d'un petit rafraîchissement.

Divers

CPU Intel Instables

• Ubit Umarov a installé le dernier microcode et il a perdu 10% de performance.,

NDLR  : Le microcode est un ensemble d'instructions de bas niveau qui permet de contrôler le fonctionnement d'un processeur (CPU).[9] Il peut être mis à jour pour corriger des erreurs, améliorer la performance ou ajouter de nouvelles fonctionnalités. En général, il est recommandé de laisser le noyau mettre à jour le microcode du CPU , car cela garantit que tout est fait correctement et en toute sécurité.

• Un article : Processeurs Intel instables : tout savoir sur l’affaire en 4 questions

Source

http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2024-08-13