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

Informations

KDU vs OpenJPEG

KDU fonctionne légèrement plus vite grâce à une meilleure utilisation de la mémoire, mais charge les images un peu plus lentement qu'OpenJPEG.
OpenJPEG est comme un instantané, il gère mieux les textures dynamiques alors que KDU affiche du gris un peu plus longtemps.
OpenJPEG semble avoir moins de problèmes de gel graphique par rapport à KDU.
L'empreinte mémoire plus faible de KDU est utile dans les cas de mémoire système limitée, avec KDU il y a un gain de 4 fps dans la même scène à la même position. Mais, le décodage JP2000 devrait avoir un impact minimal sur les fps.
KDU peut produire une lumière légèrement meilleure dans certaines scènes, mais les différences visuelles ne sont pas toujours marquées.
KDU n'est pas gratuit et OpenJPEG est libre.

Accès différencié aux fonctionnalités dans OpenSim / Mauvaise idée

Gavin Hird demande si via OpenSim on peut transmettre des avantages ou des limitations à un viewer. Cela signifie sans doute qu'il s'interroge sur la capacité d'un système à offrir des fonctionnalités différentes en fonction de certains critères, comme un abonnement.
Ubit Umarov répond que ce n'est pas possible et que ce n'est pas un de ses objectifs.
Cela signifie que le code des avantages est inutile pour les viewers OpenSim.
Partie humoristique : Ubt Umarov dit "Peut-être que certaines grilles aimeraient avoir UltraPremiumPlusHyper, ou un abonnement pour utiliser l'hypergrid. Vincent Sylvester dit de ne pas donner de mauvaise idées aux propréiatires de grilles.

Viewers

Performances du viewer

Pourquoi cela les performances ses ont autant dégradées, le fait que les utilisateurs signalent autant de gels est un phénomène assez récent.

Améliorations

Les performances des viewers devraient s'améliorer à mesure que les cartes graphiques haut de gamme deviennent moins courantes.
Vincent Sylvester a remarqué qu'un grand cache semble entraîner un rendu plus lent, ce qui est contre-intuitif.
Ubit Umarov a l'air de dire que bien que la technologie ait évolué, les résultats ne sont pas à la hauteur des attente.

Bande passante

OpenSim limite le taux maximum à environ 4000 kbit, ce qui peut affecter le rendu des images, on ne peut pas le régler plus haut même si le viewer le demande. On peut définir un nombre plus élevé dans les paramètres de débogage, mais c'est toujours limité côté serveur.
Les préférences Firestorm ne vont que jusqu'à 3000 kbit. (Pour info SL semble permettre environ 20000 kbit. Cela peut créer un goulet d'étranglement, car même si le serveur peut gérer plus de données, le viewer ne le permet pas.

Problèmes de gel

Le viewer passe trop de temps à gérer le trafic entrant et pas à rendre les image, ce qui nuit à la performance de rendu. C'est ce qui semble être responsable des gels étant donné qu'ils se produisent lors du chargement d'objets d'une région adjacente.
Le code du viewer semble manquer de mécanismes pour traiter un nombre d'objet limité par image, ce qui peut entraîner des blocages.

Gestion des données

Vincent Sylvester suggére d'examiner le code côté serveur pour réguler les données sortantes, mais cela semble être un bug du viewer. Il a essayé de changer le taux de rafale côté serveur pour réduire la quantité envoyée à la fois, mais cela ne semblait rien faire.
Le viewer pourrait bénéficier d'un mécanisme pour stocker les objets non traités afin de limiter/réguler/différer le traitement et éviter les gels.

Impact de la mémoire

La gestion du trafic entrant par le viewer implique une utilisation conséquente de mémoire ce qui affecte les performances. De plus, il faut le parcourir pour s'assurer que les objets ne sont pas sortis de la vue depuis la dernière image.
Ubit Umarov suggére que le remplissage de la mémoire GPU pourrait également être un facteur.

Conformité aux spécifications

Le viewer envoie une sorte de ratios pour les types de données, puis le serveur prend cela et fait des calculs pour déterminer le taux de données réel. Cela a dû être mis en œuvre selon les spécifications. Donc, le viewer peut envoyer des chiffres différents pour obtenir des taux de données différents en retour.
Le code de Firestorm n'est pas toujours conforme aux spécifications, ce qui peut entraîner des problèmes de performance. Ils semblent empiler beaucoup de code pour prévenir les plantages, mais tout ce code a un surcoût en termes de traitement des images.
L'ajout de nouvelles fonctionnalités, comme le PBR, pourrait avoir un impact négatif sur la vitesse de rendu. Le moteur de rendu est un désordre hybride qui peut aussi rendre le PBR. Techniquement, il est censé être plus rapide parce que le format est plus proche de ce que le moteur de rendu doit produire, mais en pratique c'est une autre histoire. Maintenant il rend PBR et Baked Physics (BP). Vincent Sylvester dit qu'il faudrait peut-être supprimer le BP pour retrouver la vitesse, mais cela reviendrait à tout détruire, les gens feraient une émeute.

  BP : technique où les calculs physiques (comme les ombres, les lumières et les interactions) sont pré-calculés et stockés dans des textures ou des données, plutôt que d'être calculés en temps réel

Dayturn

Le développement du viewer avance.
Le viewer se connecte à OpenSim, rend le monde et ce qui va avec le monde, il faut encore du travail pour HB (?) et la cuisson des avatars. Appliquer les fonctionnalités d'OpenSim codées il y a 13 ans à la nouvelle base de code n'est pas trivial par moments, mais cela avance.

Source

http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2025-05-20