Aller au contenu

« Réunion du 16-04-2024 » et « Réunion du 30-04-2024 » : différence entre les pages

De OSWiki
(Différence entre les pages)
Page créée avec « = Introduction NDLR = * Cette réunion fut '''très très compliquée à résumer'''. J'ai du zapper pas mal de choses sur les physiques.Surtout vers la fin avec une histoire de boule creuse physique et un ou plusieurs avatars à l'intérieur. * Ubit Umarov parle aussi de définir '''les frames par secondes du simulateur à 50fps'''... je ne sais pas le faire, je n'ai pas pu ajouter l'information dans le résumé. Voulait-il parler de FrameTime (voir ci-dessous... »
 
Page créée avec « = Changements du code de la semaine= === Quelques changements dans le code UDP=== * Commit : [http://opensimulator.org/viewgit/?a=commit&p=opensim&h=41ef04902f66349007689498171973cb2a5ea4e7] * 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. ** bu... »
 
Ligne 1 : Ligne 1 :
= Introduction NDLR =
= Changements du code de la semaine=
* Cette réunion fut '''très très compliquée à résumer'''. J'ai du zapper pas mal de choses sur les physiques.Surtout vers la fin avec une histoire de boule creuse physique et un ou plusieurs avatars à l'intérieur.  
=== Quelques changements dans le code UDP===
* Ubit Umarov parle aussi de définir  '''les frames par secondes du simulateur à 50fps'''... je ne sais pas le faire, je n'ai pas pu ajouter l'information dans le résumé. Voulait-il parler de FrameTime (voir ci-dessous) ? Je ne sais pas. De plus il ne donne pas toutes la suite des configurations  Update[***]EveryNFrames, ... si vous voulez essayer cette config, faites des tests. Personnellement, je remplacerais peut être aussi UpdateTerrainEveryNFrames, UpdateStorageEveryNFrames et UpdateTempCleaningEveryNSeconds.
* Commit : [http://opensimulator.org/viewgit/?a=commit&p=opensim&h=41ef04902f66349007689498171973cb2a5ea4e7]
* 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.


= Changements du code de la semaine=
=== Texture de terrain ===
=== Support SSL de Robust ===
* '''Correction d'un bug sur les changements de texture du terrain''' [http://opensimulator.org/viewgit/?a=commit&p=opensim&h=2736d36391c324c9db1f9caef1700cf080f97222]. Les changements n'étaient pas envoyés aux autres personnes dans la région.
* Correction d'un bug pour créer des clients web partagés après avoir lu la configuration.[http://opensimulator.org/viewgit/?a=commit&p=opensim&h=07d3d51c3b82f83981965e483886042632cb69d4]
=== Ajout de la capacité DispatchRegionInfo ===
* Liens [http://opensimulator.org/viewgit/?a=commit&p=opensim&h=7dda8b4154a3fe69e6b90f2dd1458981d25b97ae][http://opensimulator.org/wiki/Capabilities/fr]
===Texture de terrain ===
* Mise à jour des caractéristiques du simulateur avec une taille de texture maximale de 1024px.[http://opensimulator.org/viewgit/?a=commit&p=opensim&h=ca69544ae92e32fc21984c398101cda966655926] (Linden Lab semble se lancer à fond dans les textures de 2048px).
Il semble que les viewers affichent déjà des images de cette taille, mais n'autorisent pas le téléchargement.  


===Modules du l'ancien viewer de Diva ===
=== Connecteur MySQL d'Oracle ===
* Certains modules  dédiés à l'ancien viewer de Diva étaient activés par défauts. Ils sont maintenant désactivés par défaut mais activables depuis la configuration.[http://opensimulator.org/viewgit/?a=commit&p=opensim&h=c1c19784ff95bdd3bfa557f1b6f8b74a5636d30f]
* '''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 =
= Avertissement =
{{Avertissement_résumé|fond=pink |bord=red |message = 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 [http://opensimulator.org/wiki/Office_hours réunions du mardi] ou  sur [http://opensimulator.org/wiki/IRC le canal IRC]. Je ne fais pas partie des développeurs, ne vous adressez pas à moi pour les joindre. Merci.😉}}
{{Avertissement_résumé|fond=pink |bord=red |message = 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 [http://opensimulator.org/wiki/Office_hours réunions du mardi] ou  sur [http://opensimulator.org/wiki/IRC le canal IRC]. Je ne fais pas partie des développeurs, ne vous adressez pas à moi pour les joindre. Merci.😉}}
= Configuration et scripts=
= Noyau=
==[[Réunion_du_09-04-2024#Configuration_et_scripts |La gravité dans OpenSim (suite de la réunion du 09-04-2024)]]==
===PBR===
==== Déplacement des avatars ====
* Avec PBR[https://fr.wikipedia.org/wiki/Rendu_Physique_R%C3%A9aliste] 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.
* Essayer de déplacer un avatar avec des scripts ne fonctionne pas même en utilisant llApplyimpulse[https://wiki.secondlife.com/wiki/LlApplyImpulse] (à moins qu'il ne soit assis), c'est parce que les avatars ont leurs propres moteurs de physique.
* 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.
* Ubit Umarov va permettre la désactivation temporaire du moteur de l'avatar. Cela va aussi dépendre du moteur de physique.
* 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.
* D'après Vincent Sylvester il est possible de déplacer physiquement un avatar et de le faire planer en utilisant dans un capteur :
* 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.
llPushObject(llDetectedKey(agentNum), force, ZERO_VECTOR, 0) ;
 
== Problème  de la course à l’œuf ==
= Modules =
==== Description ====
=== Chat vocal WebRTC, Linden Lab publie des informations ===
* Cuga Raja a un jeu dans lequel un avatar se tient à l'intérieur d'un ellipsoïde creux géant avec la physique activée. Le jeu est une "course à l'œuf", l'avatar court à l'intérieur de l'œuf et l'ellipsoïde est entraîné. Dans OpenSim les jambes de l'avatar passent à travers le fond de l’œuf. Cela se produit avec les deux moteurs de physique UbODE et BulletSim mais avec des bugs différents.
* Le chat vocal WebRTC va probablement prendre beaucoup de temps pour être achevé.
====Causes possibles ====
===== Protocole =====
* Désynchronisation des objets envoyés via UDP.
* Vincent Sylvester essaie de définir '''le protocole''' et toutes les parties pour former une sorte de plan d'attaque pour ce projet.
* Limites de la force de séparation des objets et le moteur de l'avatar est très fort et peut annuler la séparation.
===== Janus WEBRTC=====
* On peut modifier la configuration. Les paramètres par défaut sont dans le fichier OpenSimDefaults.ini (même dossier que OpenSim.ini). Unit Umarov conseille de changer la configuration,  les valeurs par défaut n'étant bonnes que pour les régions où l'on danse :
* '''Le serveur web Janus''' [https://janus.conf.meetecho.com/] 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.
<pre>
* 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é.
  ; Cette valeur définit le rythme de plusieurs événements de simulation. MAIS on doit aussi modifier certains paramètres de fluidité pour que leur rythme reste similaire.
  ; FrameTime en millisecondes (ms) est le facteur .Le temps pris par OpenSimulator pour compléter la dernière image. Le temps standard est de 18,18 ms. Dans des  
  ; conditions normales, il y aura de petites variations au-dessus et en dessous de ce chiffre, probablement en raison de la faible résolution de la mise en veille des
  ; threads. Ce chiffre peut parfois augmenter si la machine virtuelle sous-jacente (Mono ou .NET) prend beaucoup de temps pour récupérer la mémoire inutilisée. Si ce
  ; nombre est constamment plus élevé, c'est que votre simulateur est surchargé.  


  FrameTime = 0.02 ; Valeur d'origine 0.0909.
=====Publication d'informations =====
  UpdateObjectsEveryNFrames = 1 ;  inchangé
* 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[http://opensimulator.org/wiki/Capabilities/fr] au serveur et en utilisent des anciennes.
  UpdateAgentsEveryNFrames = 1  ;  inchangé
* 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.
  UpdateEntityMovementEveryNFrames = 1 ;  inchangé
* 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'''.
  UpdateCoarseLocationsEveryNFrames = 250 ; passe de 50 à 250
* 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.
  etc.
* 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.
</pre>
 
* Pour que la commande '''stats show''' affiche les fps réelles vous pouvez utiliser le paramètre de configuration :
===== Problèmes =====
  Normalized55FPS = true
* Comment faire pour changer de canal et les distribuer sur le backend ?
= Viewers=
* Henri Beauchamp a posté beaucoup de choses[https://groups.google.com/a/lists.secondlife.com/g/opensource-dev/c/ZE57CVX50vk](attention lien Google) sur la liste de diffusion opensource Linden Lab [https://wiki.secondlife.com/wiki/OpenSource-Dev].
=== Contours des objets physiques ===
* 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.
====Retour sur une question de la semaine dernière ====
* Il faut aussi trouver le code de transfert pour passer d'un serveur vocal à l'autre, ce qui n'est pas encore fait.
* Est-il possible de voir les contours des objets physiques dans la viewer ? (C'est à dire la surface qui a un effet de blocage). [[Réunion_du_09-04-2024#Contours_des_objets_physiques]]
 
= 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.


==== Réponse d'Ubit Umarov ====
* 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.  
* Il n'y a pas de moyen de voir la boîte de délimitation des physiques. De toute façon ce serait faux pour le moteur de physiques BulletSim. Le type de forme de physiques est en grande partie erroné sur BulletSim. Il n'y a pas de surfaces de délimitation.  Chaque moteur fait les premières étapes de détection des collisions en utilisant sa propre idée des boîtes de rebond (bouding box). Certains moteurs peuvent en avoir une pour un objet lié... d'autres, juste pour les primitives...
* L'effet est plus important au coin opposé à 0,0 dans une région.
* Avec Firestorm, on peut voir le maillage utilisé pour les physiques, mais ça ne s'affichera pas pour  les sculpties et les prims normales. La physique utilise tout au plus des boîtes alignées sur l'axe.
  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.
* Developer -> Render Metadata -> Physics Shapes (Développeurs -> Métadonnées de rendu -> formes physiques) ne fonctionne pas , cette option montre la physique pour toutes les primitives.
==== Réponse de Gavin Hird ====
* Gavin Hird est sur que son viewer Dayturn affichera cela à partir de l'éditeur dans l'onglet Features (Attributs).
* Ubit Umarov  dit aussi que dans l'éditeur c'est beaucoup mieux, il ne montre pas les primitives normales ni les sculpties.
==== Test dans l'éditeur avec un mesh  ====
* Dans Attributs sélectionner "enveloppe ..." et cliquer sur l'oeil.
<gallery>
Fichier:Bounding_box.png||BulletSim
Fichier:Bounding box UbODE.png|UbODE
</gallery>


==== Peut-on définir une primitive d'objet lié à non physique ? ====
= Viewers=
* Oui on peut définir le format d'une primitive à "non-physique" sauf si c'est la primitive racine.  
=== Firestorm viewer et PBR===
* Une primitive enfant "non physique" agira comme une primitive fantôme sauf que le fantôme entre en collision avec le terrain, pas la primitive non physique. Ceci est vérifié avec le moteur de  physiques UbODE, à vérifier pour BulletSim.
* 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'''[https://fr.wikipedia.org/wiki/GlTF], 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=
= Source=
http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2024-04-16
http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2024-04-30

Dernière version du 30 novembre 2024 à 15:53

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