Réunion du 19-08-2025

Changements du code de la semaine

Ajout de nouvelles fonctions Linden LSL

llmapbeacon

Function: llMapBeacon( string region_name, vector pos, list options );
Demande au viewer de créer une balise pour l'utilisateur et ouvre éventuellement la carte du monde centrée sur l'emplacement.

• Commit f79e04  : Ajout d'un support pour llMapBeacon.
• Voir Linden Lab prépare de nouveaux changements

llGetRenderMaterial

Function: string llGetRenderMaterial( integer face ); 
Renvoie une chaîne qui correspond au matériau de la face.

• Commit Commit 0197ff : Ajout de llGetRenderMaterial.

llIsLinkGLTFMaterial

Function: integer llIsLinkGLTFMaterial( integer link, integer face );
Renvoie une valeur booléenne (un entier) qui est TRUE si le matériau  de la face est PBR et FALSE s'il s'agit d'une texture diffuse Blinn-Phong(en).

• Commit 4ec624 : Ajout de llIsLinkGLTFMaterial.

llWorldPosToHUD

Function: vector llWorldPosToHUD( vector world_pos );
Retourne une position vectorielle qui indique où le centre d'un HUD devrait être positionné afin qu'il apparaisse directement au-dessus de world_pos dans le monde.

• Commit 392d32 : Ajout de llWorldPosToHUD.
• Commit 15dc81 : Quelques modifications apportées à llWorldPosToHUD. D'autres modifications pourraient être nécessaires.

Bug de téléportation

• Mantis 9212 ] : Un bug empêche la téléportation entre deux régions adjacentes.
• La téléportation ne fonctionnait pas entre deux régions sur différentes instances si la cible était dans le champ de vision.
• Commit 614623 : mantis 9212 : quelques modifications apportées à LureModule et au transfert de messages.

ubODE moteur physique par défaut

• ubODE devient le moteur physique par défaut dans bin/OpenSim.ini.example et bin/OpenSimDefaults.ini
• Commit 988501 : Définir ubODE comme moteur physique par défaut

Mise à jour de libomv

• Mantis 9213 : message d'erreur [SCENEGRAPH]: Problem processing action in ForEachSOG (Problème lors du traitement de l'action dans ForEachSOG).
• Commit 676d76  : mantis 9213: mise à jour de libomv.

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

Base de données

Traitement des UUID des objects pendant l'hypergrid

Questions

• Si la prim possède un ensemble de données dans la base de données Assets de la grille d'origine et un ensemble de données différent dans la base de données de la grille d'arrivée, est-ce que les données de la grille d'arrivée remplaceraient celles de la grille de départ si on rezze la prim sur la grille d'arrivée ?
• Lorsque vous réinitialisez quelque chose à partir de l'inventaire sur une autre grille, cela modifie le groupe auquel il appartient pour correspondre à l'endroit où vous le réinitialisez. Le code de réinitialisation pourrait-il également extraire le champ « propriétaire précédent » de la base de données OSGrid plutôt que celui de l'inventaire ?
• Que se passe t-il si quelqu'un sur le réseau B utilisait délibérément le même uuid que quelqu'un d'autre sur le réseau A (collision d'UUID) ?

Problème observé

• Modification des UUID sur la grille d'arrivée, changement de propriétaire : L'UUID du « Propriétaire précédent » d'un objet appartenant à Obert Taham était celui d'une personne qui pourrait revendre l'idée dans sa boutique sur OSGrid. L'objet original est « non transférable », mais il est très facile de contourner cette restriction.
• Le problème pourrait-il être causé par quelqu'un qui en a pris possession en mode Dieu ?
• Parfois le dernier propriétaire ou le champ créateur affiche simplement « chargement en cours »... parce que les données sont manquantes ou ne peuvnt pas être converties en nom réel.

Discussion

• Le code suppose que les UUID sont uniques dans l'univers, c'est une limitation de l'hypergrid.
• Normalement, toutes les informations nécessaires sont dans l'inventaire. Les objets sont sérialisés dans l'inventaire. C'est en gros le même code que pour les OAR.
• Ubit Umarov a fait un test pendant la réunion avec un alt et il n'a pas observé de problème. Il ne sait pas comment l'UUID de l'ancien propriétaire peut avoir été remplacé. Il faudrait avoir plus d'informations sur le parcours de l'objet.
• Toutefois Vincent Sylvester signale que la table inventoryitems ne comporte pas de champ lastownerID, seulement owner et creator. La table inventoryitems enregistre les détails relatifs aux biens personnels de l'avatar (assets). Le code du rezze est compliqué, il récupère en quelque sorte les données de l'inventaire et des assets pour construire le SOP, mais il n'y a pratiquement aucun code qui interagit réellement avec le dernier propriétaire pour le définir comme quelqu'un d'autre, cela n'apparaît que dans le contexte de l'identifiant de groupe. Vincent Sylvester dit qu'il peut se tromper mais il pense que lors d'une téléportation hypergrid, l'utilisateur ne conserve pas les informations relatives aux assets provenant de la région d'où ils proviennent. Il se demande si les données de transfert sont extraites de la région où l'objet est rezzé. Parce que l'objet doit extraire le dernier propriétaire à partir d'autre chose que l'inventaire utilisateur.
• Il y aurait 3 possibilités pour que l'UUID du dernier propriétaire change :

1. soit la région d'origine rapporte des données erronées,
2. soit il y a une interaction avec l'identifiant du groupe,
3. soit il s'agit potentiellement d'un objet dont le dernier propriétaire de la partie racine est corrompu d'une manière ou d'une autre.

Ce sont vraiment les seuls endroits qui interagissent pour construire le SOP qui sert de base à la demande de données du viewer.

• Finalement Ubit Umarov clôture la discussion en répétant que ces données sont sérialisés.

NDLR  : La sérialisation en informatique est le processus de conversion d'un objet en un format qui peut être facilement stocké ou transmis et ensuite reconstruit ultérieurement.

• La collision des UUID (UUID identiques mais rôles différents sur deux grilles) est un autre problème.

Tests

Suppression de System.Drawing pour le remplacer par SkiaSharp

Le test

• Vincent Sylvester a fait un test, il a supprimé System.Drawing et l'a remplacé par SkiaSharp. Il prépare une éventuelle suppression à venir de System.Drawing .

SkiaSharp

• Microsoft recommande d'utiliser SkiaSharp à la place de System.Drawing mais cela semble moins facile à mettre en œuvre. Skiasharp est une interface simplifiée qui enveloppe la bibliothèque graphique open-source Skia de Google. Skia présente un réel avantage : certaines fonctions utilisent en interne des opérations mémoire beaucoup plus rapides.

Bilan

• SkiaSharp fonctionne mais il faudra faire pas mal d'ajustements dans libomv. Les modifications de code sont assez minimes. System.Drawing peut disparaître, tout ira bien.
• Actuellement aucune raison de le remplacer System.Drawing tant que cela fonctionne correctement.
• system.draw a en fait moins de dépendances que SkiaSharp. Les dépendances de SkiaSharp sont répertoriées sur Nuget : https://www.nuget.org/packages/SkiaSharp/#dependencies-body-tab. OpenSim a besoin de toutes ses dépendances pour TOUTES les plateformes.
• Actuellement, seuls Windows, macOS et Android sont pris en charge, tandis que le support pour Linux semble absent. Il existe une autre option que SkiaSharp, mais elle semble moins facile à mettre en œuvre.
• La situation la plus contraignante serait de dissocier System.Drawing de l'arborescence source de .NET pour en faire un projet indépendant .

NDLR  : Dans ce cas, OpenSim aurait un fork de System.Drawing qui s'ajouterait aux bibliothèques de OpenSim-libs.

Source

http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2025-08-19