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

NDLR :

Ce schéma a été élaboré pour illustrer le flux de données lors de l'utilisation de l'inventaire dans OpenSimulator. Bien qu'il vise à représenter fidèlement le processus, des erreurs peuvent subsister. Les retours et suggestions sont les bienvenus pour améliorer cette représentation.

Code principal

Les inventaires

Code du noyau et du viewer

Dan Banner par l'intermédiaire d'Hiro Protagonist demande des précisions sur le code de gestion d'inventaire OpenSim qui s'exécute quand un utilisateur se connecte pour la première fois.
Ubit Umarov désigne les fonctions nécessaires à la création des entrées d'inventaire de base dans OpenSimulator :
- Fonction protected XInventoryFolder CreateFolder(UUID principalID, UUID parentID, int type, string name)
- Fonction public bool StoreFolder(XInventoryFolder folder)
Ubit Umarov vient de mettre à jour notre code pour ajouter les matériaux aux nouveaux inventaires.
Le code responsable des messages d'erreur dans le viewer signalant que l'inventaire est cassé et qui pourrait intéresser Dan Banner est dans le viewer. Le viewer veut avoir des dossiers corrects, c'est tout.

Structure des inventaires

Les types de dossiers et d'objets

La seule chose qui change avec le temps dans les inventaires sont les types de dossiers. Ils sont facilement rectifiable dans la base de données, cela ne nécessite pas d'effacer l'inventaire.
Les types de dossier d'inventaire sont listé dans https://bitbucket.org/opensimulator/libopenmetaverse/src/master/OpenMetaverseTypes/Enums.cs.
On peut les trouver aussi sur le wiki officiel d'OpenSimulateur à cette adresse.
Seuls les dossiers racine ont le type != -1.
Le seule problème connu à propos des objets eux-mêmes est la confusion entre les textures et les snapshots. Mais, cela se produit également dans les IAR. Donc, cela ne s'arrangera pas en les rechargeant.
Les dossiers et les objets de l'inventaire ne sont qu'une vaste référence aux ressources, ils ajoutent un peu de métadonnées, mais les tables ne stockent rien qui pourrait briser les ressources de quelque manière que ce soit. Les seuls changements connus qui ont été apportés à l'inventaire dans le sens d'une modification sont les types de dossiers et un type d'objet pour les textures/photos. Tout cela remonte à une dizaine d'années. Avant cela, nous ne pouvons pas vraiment déterminer ce que cela aurait pu être parce que git ne remonte que jusqu'à cette date.
L'inventaire conserve juste un UUI pour référencer un asset, il essaie donc de le récupérer. Tant que l'entrée n'est pas touchée, il essaiera simplement.

Script de création d'inventaire

Fonction PHP public function createinv($avuuid) pour créer un inventaire, proposée par Vincent Sylvester
Il manque les matériaux, mais de toute façon le viewer le crée.

Bibliothèque OpenSim

La bibliothèque opensim en bas de l'inventaire est fournie par la région directement.

Service d'assets

Différents types de service d'assets

Fsassets est un service d'assets destiné aux grandes grilles. Fsassets déduplique les assets par hachage des données du fichier. Plusieurs entrées d'assets (Ndrl : plusieurs UUID d'inventaires ) utilisent les mêmes données sur le disque. Dans fsassets original, les métadonnées sont stockées sur MySQL, les données sont stockées sur des fichiers disques. Les services d'assets peuvent également être interrompus avec des métadonnées pointant vers des données perdues. (Ndrl : c'est à dire qu'un fichier disque peut manquer ou être abimé et la base de données via l'UUID de l'inventaire ne pourra pas trouver les données nécessaires à l'affichage dans le viewer.)
Des systèmes similaires à Fsassets existent, comme SRAS.
OSGrid utilise actuellement un service d'assets propriétaire, pas celui d'opensim quelque chose de personnalisé par Melanie_T.

Réparer un serveur d'assets

Scripts de vérification des inventaires

Vincent Sylvester a écrit un script de vérification des inventaire. Une page de wiki OpenSimulator lui est consacrée. Ce script signale les mêmes erreurs que le viewer. La page du wiki liste les moyens de rectifier la plupart de ces erreurs.
D'autres problèmes que ceux signalés par le viewer ou le script de vérification peuvent exister, mais ils ne devraient pas causer directement de problèmes. En général, les erreurs de types d'éléments d'inventaire ne provoquent pas de problème d'asset.

Utilisation des IAR

Une IAR est juste une archive, elle contient un dossier pour la structure et les données de l'inventaire ainsi qu'un dossier contenant les assets que le collecteur d'UUID a récupéré pendant le processus de sauvegarde.
Vider un serveur d'assets et utiliser des IAR est une façon de nettoyer les poubelles d'un serveur d'assets, en repartant de zéro.
On peut également utliser des IAR pour réparer le serveur d'assets. Si vous décompressez l'IAR, vous obtiendrez un dossier d'assets contenant les données des assets référencés par les UUID qu'ils avaient lors de la création de l'IAR. Il suffit ensuite d'utiliser les données de l'asset contenu dans l'IAR pour réparer l'asset cassé (vérifier qu'il est réellement cassé) dans le serveur d'assets.
Il faut vérifier si les données sont cassées parce que le problème peut venir des métadonnées stockées dans la base de données et dans ce cas, cette méthode ne fonctionnera pas.
Ainsi, il faut demander aux utilisateurs des IARs pour aider à la récupération.
L'IAR peut faire des dégâts, des duplications et peut ne pas contenir les assets appropriés. Mais, tout le monde ne se soucie pas de faire une IAR. Une partie des utilisateurs peuvent ne pas se connecter depuis plusieurs années et n'en feront jamais. Parfois, (comme sur Osgrid) la sauvegarde d'IAR est si lente que beaucoup se découragent et n'en font pas.

Informations

Maintenance d'Osgrid

Problème des inventaires et assets

L'équipe d'OSGrid se confronte à des problèmes liés au stockage des assets de la grille.
Le stockage des assets d'OSGrid est saturé, et un problème de taille de bloc de système de fichiers a aggravé la situation, rendant inefficace l'utilisation de l'espace. Il semble qu'une partie du stockage des assets avait une taille de bloc de système de fichiers (cluster) trop grande, ce qui a conduit à un gaspillage d'espace important.
Un problème autre problème est qu'il existe beaucoup de choses très anciennes avec des types incorrects.
Un processus a été lancé pour réécrire tous les assets dans une taille de disque appropriée, mais cela a entrainé des pertes importantes d'assets. Il est possible que les pertes augmentent encore. Ce qui est préoccupant pour la gestion de la grille.
Ceph utilise une architecture distribuée, ce qui signifie que les données sont réparties sur plusieurs nœuds (serveurs) pour assurer la redondance et la tolérance aux pannes. Si la configuration n'est pas optimale, cela peut entrainer des problèmes de gaspillage d'espace.
Il faut trouver une solution pour nettoyer les inventaires afin de faciliter la réparation des assets, ce qui pourrait être une étape nécessaire pour résoudre les problèmes de perte de données.
Le vrai problème est de récupérer tous les dossiers et les items, de les valider et de les corriger et de faire cela le plus proprement possible.

État des assets d'OSGrid

Les inventaire de certains utilisateurs comme Gaving Hird sont affectés par la présence d'assets anciens de 2008. Il est impossible de trouver certains des éléments les plus basiques de l'avatar. Donc on ne peut rien faire pour le changer cela, l'inventaire ne trouve pas les éléments de librairie nécessaires.
Pour la plupart des utilisateurs, les assets sont dans le cluster et devraient fonctionner une fois la réparation du cluster terminée. On parle d'un cluster de quelques TB de données. Malheureusement, il semble que le cluster ait perdu des tonnes d'assets.
Osgrid est aussi confrontés à la gestion d'utilisateurs qui sont là depuis si longtemps que de nombreux changements dans la façon dont les choses fonctionnent se sont produits. Des changements venant d'OpenSim, d'autres d'osgrid, d'autres de Linden Lab, d'autres encore de divers développeurs de Viewers - et les inventaires d'Osgrid portent les marques de tout cela.
Orgrid doit aussi faire face à d'anciennes spécificités qui ne sont plus d'actualités mais qui ont encore des effets sur la grille.
Suitcase de l'hypergrid lorsqu'elle a été introduite pour la première fois a causé toutes sortes de problèmes et, c'est peut-être encore le cas.
OSGrid utilise actuellement un service d'assets propriétaire, pas celui d'opensim quelque chose de personnalisé par Melanie_T.

Nombre d'utilisateurs

D'après Hiro Protagonist un COUNT(*) sur la table des utilisateurs causerait probablement des problèmes pendant des jours avant qu'il soit terminé.
Ce qui est important pour une grille c'est de faire la différence entre les utilisateurs actifs et inactifs.
Sur le site le nombre total d'utilisateurs indiqué est 161654 à ce jour. Hiro Protagonist se demande à quel point ces chiffres sont exacts. Il pense que c'est trop peu par rapport à la réalité.
Les utilisateurs actifs sont à peu près 4800 , mais chaque personne a probablement deux comptes, ce qui signifie qu'il n'y a en réalité que 2400 utilisateurs distincts actifs.

Solutions mises en œuvre et proposées

Description d'un script de réinitialisation de l'inventaire des avatars pour les grilles et les standalones d'OpenSimulator : https://pastebin.com/HmVaDGS5
Il faudrait commencez par lancer le script de vérification de l'inventaire de Vincent Sylvester et corrigez les types de dossiers, cela empêchera au moins les viewers de se plaindre à ce sujet. Pour restaurer les ressources à partir des IAR, il n'est pas nécessaire de les charger, il suffit d'extraire les ressources et de les comparer à ce qu'il y a sur le disque. Si une ressource est cassée, il suffit de remplacer les données elles-mêmes, sans toucher à la base de données.
Donc, il faudrait rassemblez le maximum d'IAR des utilisateurs d'Osgrid. Ensuite, il faut extraire le dossier des assets, parcourir la base de données pour voir ce qui est cassé, et remplacer ce qui doit l'être. Si un élément d'inventaire indique que l'asset (UUID) n'a pas été trouvé, il est possible de le rechercher et le retrouver dans les données d'asset de l'IAR.
OpenSim est basé sur une base de données, donc tout ce qui est cassé dans l'inventaire peut être réparer avec un peu de SQL].
Si une solution radicale est envisagée pour éliminer complètement l'inventaire, cela pourrait entraîner de grandes pertes pour les gens, et il n'est pas évident que cela soit nécessaire. Bien que cela puisse être perçu comme un moyen de nettoyer des décennies de problèmes, il serait possible de le faire de manière plus délicate.

Taille des textures

Question

Linden Lab plafonne la taille des textures. Quelle taille est supportée par le viewer ?

Réponses

Toutes les version OpenSim 0.9.3 permettent 2k ( ndlr : 2K fait référence à une résolution où la plus grande des mesures de pixels est supérieure à 2000 pixels. ). La région n'a aucune idée de la texture chargée.
Les derniers viewers les soutiennent les textures de 2048 mais pas *tous* les viewers. Ils peuvent les recevoir mais le moteur de rendu tombe en panne sans le support adéquat. En fait, il envoie juste un drapeau que seuls les nouveaux vewers connaissent.
Ce serait une bonne pratique de ne pas faire exploser de grosses textures si le viewer ne le supporte pas. Les gens téléchargent 2k pour un verre à boire parce que c'est ce qui est fourni avec le modèle 3D. Certains objets très grands peuvent bénéficier de 2048 mais c'est une exception à la règle. Il faut adapter la taille de la texture à la taille et au nombre d'objets sur la région.

Développeurs actifs d'OpenSim

Les développeurs principaux

Les présents

Parmis les participants à la réunion, Ubit Umarov et Andrew Hellershanks sont développeurs principaux d'OpenSim.
Ubit Umarov porte le projet depuis 5 ans. C'est vraiment la star de l'émission.
L'implication dans le projet d'Andrew Hellershanks a été principalement dans des domaines autres que le corps principal du code.

Les absents

Les autres développeurs principaux qui ne sont pas présents sont : Melanie, Diva, et Misterblue.
Tous les core devs ne viennent pas régulièrement à cette réunion. Ils sont plus nombreux sur IRC.
Misterblue travaille sur la partie WebRTC en ce moment. Pour l'instant il le fait comme son propre projet, pas comme une partie du noyau.
Diva n'est pas très active, elle a au moins géré un peu la partie Wifi sur github, mais c'est à peu près tout.
Nebadon pourrait toujours être techniquement un membre du noyau, mais il n'est plus en train de travailler sur des choses RL depuis quelques années maintenant.
Selon les règles, un core dev, toujours un core dev.
A l'exception de WebRTC, il n'y a pas eu beaucoup de problèmes urgents ici. Le système d'exploitation a été assez stable récemment.

Plus d'informations

Contact

Liste de diffusion
IRC
Email, Discord

Source

http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2025-02-04