Réunion du 09-01-2024

Changements du code de la semaine

• correction mineure pour le PBR (matériaux) pour les pièces jointes [1]
• changements "cosmétiques" [2][3]

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

Modules

Recherche

• Vincent Sylvester se demande pourqoi le module de recherche d'OpenSim n'est pas dans le noyau. Il dit quà part les problèmes de webroot, le module lui-même n'a pas changé du tout et que très peu de monde utilise un module différent pour la recherche, s'il en existe un autre.

Projets en cours / Infos

Osgrid

• Maintenance de la grille Osgrid : OSgrid utilisera une nouvelle version de la 0.9.3 lorsque la grille reviendra en ligne. Il y aura des changements dans Opensim.ini et gridcommon.ini en ce qui concerne les listes muettes et les messages instantanés hors ligne. [4]

Petit bilan du passage à dotnet 6

• Pas de retours depuis le passage de master à dotnet6 : ceux qui utilisent Git devaient déjà utiliser dotnet6.
• Il y a eu quelques plaintes sur le fait que les scripts ne sont parfois pas transférés, parce que leurs binaires ne sont pas directement compatibles.
• Quelques problèmes vites résolus avec la Mantis.
• Les performences sont légèrement en hausse.
• Au fur et à mesure que dotnet6 progresse, les choses deviendront de plus en plus incompatibles, en particulier avec PBR.

Modules Addons de Andrew Hellerhanks

• Ils seront déplacés de Github vers Sourceforce [5] en raison des problèmes liés à l'authentification à deux facteurs exigée par Github.
• Gavin.Hird utilise aussi Kallithea [6] mais il semble qu'il ne soit plus maintenu.
• NDLR : pour info Framagit [7] qui est une instance de Gitlab maintenue par Framasoft. Vous pouvez créer des comptes et l'utiliser gratuitement.

Prochaine réunion

• Éventuelle région de remplacement : http://grid.xmir.org:8002/barcola . Attente près de l'aire d'atterrissage et choix d'une salle après l'arrivée des participants. Les retardataires peuvent vérifier sur la carte s'il y a un groupe de points bien serrés.
• NDLR : comme la grille Osgrid semble mise à jour et que tout fonctionne il est peu probable que la réunion du 16 janvier soit déplacée.

Viewers

Sharpview

• Ajouts de dispositifs pour le passage de régions. Des tests sont nécessaire, cela ne fonctionne pas assez bien.
• Pas encore de test pour les véhicules sur OpenSimulator.

Passage de région

• La plupart des viewer enregistrés par SL ont accès à la physique du moteur Havok. [8], sinon il faut utiliser celui d'Alchemy pour opensim, sinon impossible de traverser une frontière avec un véhicule.
• La plupart du code pour les passages de frontière se situe dans le fichier indra/newview/llviewerobject.cpp du viewer.
• La région décide où se trouve l'objet(serveur) le viewer dit juste "bouge" (client),c'est la partie UDP. S'il y a une perte de paquets UDP, ce que veut l'utilisateur peut se perdre. La région dit au viewer ce qu'il doit faire et en retour il envoie un rapport. Les régions décident des positions, elles dirigent la physique et les scripts. Parce que le "ne peut pas bouger" est plus rare que le "peut bouger", la plupart des vérifications se font après qu'il soit appliqué, c'est pour ça qu'il y a de l'élastique sur les lignes de bannissement et autres.
• Dans les viewers, il y a une seconde délibérée pendant laquelle aucune nouvelle image n'est rendue pendant la traversée, un certain nombre d'images ne sont pas rafraîchies. L'utilisateur est généralement concentré sur l'avatar en train de traverser, donc tout ce qui se passe dans le cadre n'a pas d'attention. C'est localisé à l'observateur, tout le reste se passe normalement.

Problème

• Sur OpenSim les passages de région en diagonale explosent à cause de la façon dont les croisements fonctionnent en interne, nous ne pouvons tout simplement pas déplacer les données assez rapidement. Les régions ne parlent pas avec les régions en diagonale. Le problème vient peut-être du protocole, comment les mises à jour sont envoyées via UDP. La plupart des cas, il y aura 2 croisements en séquence rapide.Le problème est que si vous vous déplacez à une diagonale de 256,254 par exemple, vous êtes d'abord placé dans la région latérale, puis vous passez instantanément dans la région diagonale. OpenSim ne peut pas traiter ces données en moins d'une seconde. Si vous atteignez exactement 256,256 et que vous vous déplacez rapidement, vous serez placé dans la région diagonale. C'est encore plus vrai si la seule région disponible est la région diagonale. Si vous vous arrivez dans le coin et que vous n'avez que la région du coin disponible pour traverser, cela fonctionne beaucoup mieux, c'est la région sur le côté qui obtient le déclenchement de la traversée qui casse tout.

Solutions

• Une solution : mettre une grosse prim sur les coins avec le message "non, pas de croisement ici". 😀
• Une solution plus efficace serait d'essayer l'idée de la boîte de délimitation, forcer le croisement en diagonale.

Édition d'un terrain

• Sur SL la terre s'étend sur 16m à l'extérieur du bord pour la physique, sur OpenSim la marge est plus réduite.
• À travers la frontière d'une autre région sur SL, on obtient le terrain de l'autre région. Sur OpenSim il n'y a pas ce genre de partage. Les régions sont isolées. C'est une bonne chose, mais cela implique aussi certains problèmes.

Source

http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2024-01-09