Réunion du 18-06-2024

De OSWiki
Aller à la navigation Aller à la recherche

Changements du code de la semaine

PBR de terrain

  • Problèmes : perte d'un flag et choses mineures. Le survol de l'avatar avec la souris ne fonctionnait pas.
  • Commit 8e874d Quelques corrections

Code redondant : 2 anciennes routines pour une capacité

  • Commit 644af5
  • Récemment, la mauvaise routine a pris le dessus tuant la fonctionnalité.
  • La mauvaise routine a été supprimée.

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


Bugs

SqlLite

  • Mantis 0009139: SQLite Issue - FATAL error: System.InvalidCastException
  • Problème de migration avec PBR terrain.
  • Solution :
1.Faire un OAR
2a. Renommer opensim.db en opensim.db_old pour pouvoir revenir en arrière.
ou
2b1. Éditer OpenSim.db avec un outil comme "db browser for sqlite"[1] ou SQLite Manager dans Firefox
2b2. Mettre regionstore migration à 0 dans la table migrations.

Bug de recherche : UUID de parcelles identiques dans plusieurs régions

  • Dans ce cas la recherche avec une clé sur les UUIDs échoue.
  • Solution pour l'utilisateur: éditer manuellement l'UUID dans la table land [2].
  • Solution pour les développeurs :Changer l'analyseur et la structure de la table de recherche pour utiliser à la fois la région et l'uuid de la parcelle.
  • Les parcelles ont 2 types d'UUIDs:
    • un UUID visible qui est un faux UUID. Il apparait dans le viewer sous "Monde/À propos du terrain/ Général/ ID Terrain". Il n'est pas généré comme les autres UUID. Il n'est pas stocké dans la base de données, il est généré dynamiquement au démarrage à partir de l'emplacement de la parcelle. Comme X et Y peuvent ne pas être unique, si une parcelle est à l'intérieur d'une autre parcelle, OpenSim a créé ce faux UUID. Parfois, il y a des échecs.
      //Code de génération du faux UUI :
      public static UUID BuildFakeParcelID(ulong regionHandle, uint x, uint y)
       {
           byte[] bytes =
           {
               (byte)regionHandle, (byte)(regionHandle >> 8), (byte)(regionHandle >> 16), (byte)(regionHandle >> 24),
               (byte)(regionHandle >> 32), (byte)(regionHandle >> 40), (byte)(regionHandle >> 48), (byte)(regionHandle >> 56),
               (byte)x, (byte)(x >> 8), 0, 0,
               (byte)y, (byte)(y >> 8), 0, 0 
           };
           return new UUID(bytes, 0);
       }
      
    • un UUID normal socké dans la base de données dans land.UUID

Informations

Impact des changements du code Linden Lab sur OpenSim

  • la rapidité des changements apportés et le manque de tests adéquats sont inquiétants et peuvent entraîner des problèmes de stabilité et de qualité.
  • problèmes spécifiques évoqués/ devinés :
    • le déplacement des inventaires vers l'AIS (Agent Inventory Service)[3] qui par exemple construit l'arbre d'inventaire complet sur l'AIS en un seul appel.
    • les miniatures apportent des problèmes de performance, tels que des ralentissements et des chutes de trames, ainsi que des problèmes d'ergonomie, comme le fait de cacher l'inventaire lors de l'affichage des miniatures.
    • le cache : le système ne récupère pas l'intégralité de l'inventaire avec un cache vide. Cela peut révéler un problème de gestion du cache ou de récupération des données. Il pourrait y avoir des problèmes plus profonds à résoudre pour garantir un fonctionnement optimal du système comme la suppression de code d'inventaire dont OpenSim a besoin.
    • l'utilisation de threads multiples induits par l'utilisation de callbacks
    • l'implémentation de webRTC : le principal problème réside dans des défis techniques liés au manque de documentation, des pressions pour accélérer le processus d'intégration et des progrès lents dans le développement en arrière-plan de WebRTC.

Viewers

Firestorm

  • Contexte / Terrain PBR
  • Malgré des problèmes techniques, la fausse capacité VETPBR a été ajoutée au viewer. Le terrain PBR d'OpenSim fonctionne sur Firestorm Bêta
  • Problèmes  : À partir de maintenant, il y a deux ensembles de textures de terrain. Les anciens viewers verront et pourront remplacer les textures de terrain comme avant, les nouveaux viewers avec le terrain PBR verront et pourront remplacer définir les terrains PBR. Jusqu'à ce que les développeurs changent cela, il faudra maintenir les deux ensembles pour que le terrain n'apparaissent pas gris à une partie des visiteurs. Cela implique qu'il faudra utiliser deux viewers de deux générations différentes pour configurer le terrain d'une région.
  • La base de code de Firestorm provoque des problèmes étranges avec l'inventaire, problèmes plus prononcés sur les versions bêta avec un cache propre. Cela peut entraîner des plantages ou des erreurs occasionnelles. Il pourrait y avoir un problème avec le multitâche dans FireStorm, peut-être un vieux problème, aggravé par les changements récents.
  • Mise à jour de Firestorm VR Mod avec PBR

Sharpview

  • Travail actuel : ordre des priorité de chargement des meshs lorsque la caméra se déplace.
  • WGPU [4]:Joe Magarc utilise cette bibliothèque qui gère Vulkan[5], Metal[6], OpenGL[7], DirectX 12[8], Android[9] et WebGPU[10]. WGPU est une bibliothèque graphique sûre et portable pour Rust[11], basée sur l'API WebGPU. Elle est adaptée aux graphiques d'usage général et au calcul sur le GPU.
  • Utilisation du langage RUST
    • De nombreux problèmes se posent parce que les bibliothèques de code de bas niveau pour RUST ne sont pas optimisées pour les performances. Il faut faire ce travail alors qu'il aurait pu être fait par d'autres depuis longtemps et cela prend du temps au lieu d'ajouter des fonctionnalités de jeu.
    • Rust a été conçu pour offrir à la fois une gestion sûre de la mémoire et des performances élevées en évitant l'utilisation d'un ramasse-miettes [12] ou récupération de mémoire.
    • Joe Majarac a déjà passé 3,5 ans sur ce projet et Gavin.Hird prédit qu'il lui prendra encore 10 ans.
    • Sharpview fonctionne sous Windows et Linux, et fonctionnerait probablement sous MacOS si la volonté était de franchir les obstacles d'Apple.

Source

http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2024-06-18