Réunion du 06-08-2024

De OSWiki
Aller à la navigation Aller à la recherche

Changements du code de la semaine

Références nulles

Temps de calcul CPU

  • Commit d9cfb3: amélioration du temps de calcul CPU pour la résolution des scripts, en particulier sous Windows.
  • Remplacement de datetime par stopwatch.
  • Le temps de résolution passe de 15ms à 0.1μs sur la plupart des systèmes Window et de 1ms à 0.1μs sur GNU/Linux.
  • Questions débattues pendant la réunion : a t-on besoin d'une vitesse de calcul aussi rapide dans OpenSim, quels impact cela pourrait avoir sur le CPU ?

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


Modules

Optimisation de la génération des carreaux de carte

  • Il y a plusieurs mois Vincent Sylvester avait commencé à optimiser le code de génération des maptiles, il avait déplacé la plupart des tâches de génération dans un thread indépendant.Ainsi, la génération des carreaux de cartes ne bloque pas le reste du programme, ce qui améliore son efficacité.
  • Grâce à cette optimisation, Vincent Sylvester a pu créer des milliers de carreaux de carte à partir d'une seule tuile (map-1 tiles) en environ 20 minutes, pour créer des niveaux de zoom.
  • Amélioration supplémentaire avec le multithreading : le traitement des carreaux un par un et leur ajout à des fichiers n'était pas assez efficace. Vincent Sylvester a donc décidé de paralléliser l'ensemble du processus. Il a utilisé plusieurs threads pour traiter plusieurs carreaux en même temps, ce qui permet de gagner du temps.
  • Résultat, il a pu générer 5085 tuiles de niveau de zoom pour 13056 carreaux de carte en seulement 144,23 secondes.
  • Ce code s'exécute sur un minuteur et vérifie si de nouveaux fichiers map-1 sont trouvés en fonction de la date, puis, normalement, il ajoute les niveaux. Dans OpenSimulator, lorsque 20 régions uniques doivent être intégrées à un même niveau de zoom, leur enregistrement sur la grille déclenche un minuteur pour ajouter le carreau de carte de ce niveau. Si une région est démarrée pendant ce processus, cela réinitialise le minuteur, certaines tuiles ne sont pas générées donc, elles manquent. En modifiant le système pour qu'il vérifie régulièrement la date et l'heure des fichiers et ajoute tous ceux qui manquent, ce problème peut être résolu. Les autres améliorations visent à rendre le processus plus rapide et à permettre le rafraîchissement de tous les niveaux.
  • Maintenant le goulot d'étranglement ne se situe plus au niveau du code mais au niveau des CPU et des disques. Il faut encore nettoyer le code et résoudre de petites incohérences.

Viewers

Viewer Dayturn

  • Pas beaucoup d'évolution depuis quelques semaines, ajout d'un peu de code et nettoyage.
  • La base du code Liden Lab devient de plus difficile à suivre.

Problèmes liés au récentes modifications de Second Life

Second Life

  • Sur certains forums, il semble que quelques clients de Linden Lab sont fatigués par les changements et annulent leurs abonnements. Les gens ont passé des années à créer leurs environnements, et soudainement leur simulation ne ressemble plus à rien à moins de tout renouveler. Ils achetent des assets PBR alors qu'il suffit de désactiver une option.
  • Beaucoup de gens sur les groupes de Firestorm demandent de désactiver PBR. Cool VL Viewer permet cela et il implémente même "Advanced Lighting Model" ALM (le mode de rendu avancé). Il a 3 de moteurs de rendu ou plus.
  • Mais Liden Lab va probablement rendre PBR obligatoire à cause du viewer mobile. Ils poussent tous les viewers tiers à passer à PBRet à WebRTC rapidement. Ils sont forcés par les investisseurs. Il semble que Liden Lab dépensent beaucoup de dollars, ils embauchent beaucoup de codeurs.

Firestorm et OpenSim

  • Problèmes avec PBR : Depuis vendredi, il était impossible d'utiliser une version fonctionnelle de Firestorm avec PBR dans OpenSimulator.
  • Les seules versions qui fonctionnaient ont été retirées.
  • Un nouveau lien a été ajouté, permettant au moins de récupérer les "bakes" d'avatar, mais cela ne concerne que les textures de peau, ce qui fait que l'avatar apparaît nu.
  • Les bake sur meshes (BOM) dépendent des avatars système et si l'avatar système ne fonctionne pas, le BOM ne fonctionnera pas non plus. BOM est en fait un système qui permet de faire fonctionner les wearables sur le maillage sans avoir besoin de couches alpha... etc.
  • Gavin Hird pense que seuls les BOM fonctionneront dans les futurs viewers pour s'adapter aux avatars des viewers mobiles.

Migrations vers OpenSim ?

  • Vincent Sylvester se demande si cela veut dire que tous ceux qui ont encore de la matière grise vont migrer de Second Life vers OpenSim ?
  • C'est possible mais, il existe quelques raisons qui ne le permettent pas.
  • Certains sont tout simplement trop investis. Une chose est de déplacer votre présence, une autre de déplacer toutes vos affaires.
  • Second Life ne rend très difficile un déménagement. L'importation de mesh est bloquée, ce qui rend la tâche presque impossible.
  • Même pour les créateurs, qui en théorie devraient avoir tout ce qu'il faut pour déplacer leur contenu, c'est un travail colossal. Sans compter les dépendances aux choses achetées.

Importation de mesh depuis SL vers OpenSim

  • La dernière fois qu' orbert tatham a essayé d'importer un mesh depuis SL, la couche physique a été complètement détruite. Il a essayé toutes les solutions qu'il a pu trouver expliquées sur internet.
  • Collada exige que chaque objet séparé ait sa propre correspondance de collision qui lui soit assignée, ce qui peut être pénible à mettre en place, mais c'est une pratique standard de développement de jeux.
  • Ubit Umarov rappelle que les options "analyse" changent le format du maillage et rend les choses plus complexes. Cela peut faire échouer l'importation d'un mesh. Mais orbert tatham semble dire que même sans utiliser l'analyse, cela ne fonctionne pas.
  • Gavin Hird a cacher toutes les fonctionnalités d'analyses sur le viewer Dayturn pour OpenSim, il dit que cela crée beaucoup de confusions (ndrl: pour être polie).

Quelques solutions pratiques proposées par les participants

  • Utilisation de maillages de physique simples : Vincent Sylvester mentionne qu'il crée un mesh de physique et dans les propriétés physique il définit le niveau de détail sur "Lowest" (le plus bas niveau de détail), ce qui permet de contrôler le niveau de détail et d'assurer de bonnes performances physiques.
  • Création de colliders (volume de collision) simples : Ubit Umarov suggère que dans de nombreux cas, ajouter quelques boîtes ou sphères peut suffire à créer des colliders efficaces, ce qui simplifie le processus de création de collisions.
  • Téléchargement et réparation de meshes : Vincent Syslvester propose de télécharger un mesh cassé et de créer des boîtes pour les parties, puis de les assigner, ce qui peut aider à corriger les problèmes de collision. Il mentionne également que les versions récentes de Blender ont modifié l'emplacement de certains outils, ce qui peut compliquer ce processus.
  • Éviter les trous pour les fenêtres : Vincent Sylvester dit qu'il ne crée plus de trous pour les fenêtres, car cela peut compliquer la gestion des collisions, en soulignant que les fenêtres ne sont pas des portes.
  • Utilisation de la version la plus récente d'outils : Gavin Hird fait référence à une nouvelle version d'un outil (meshoptimizer) qu'il prévoit de tester, ce qui montre l'importance de rester à jour avec les outils disponibles pour améliorer la gestion des meshes.
  • Importance de la séparation des meshes : Ubit Umarov souligne qu'il est souvent nécessaire de diviser le mesh afin que chaque upload soit une seule prim, ce qui est une bonne pratique pour la gestion des objets dans l'environnement virtuel.
  • Création de physiques minimales : orbert tatham qu'il crée une physique minimale, grossièrement façonnée comme les éléments visibles, ce qui peut être une approche efficace pour simplifier la gestion des collisions.
  • Utiliser des primitives : La construction de Prim est un art en soi mais il n'y a plus beaucoup de gens qui le maîtrisent. On peut construire des maisons et autres avec des primitives à l'échelle, les exporter en OBJ et les réimporter en meshes.

Utilisation de glTF

  • Second Life est en train de remplacer Collada et d'utiliser glTF dans le viewer. Ubit Umarov et Vincent Sylvester n'ont pas l'air d'apprécier ce changement. Ils poussent les viewer tiers à faire pareil mais le peuvent-ils ?
  • D'après ce que Ubit Umarov a lu, Second Life prévoit de remplacer tous les éléments existants (comme les modèles, les textures, etc.) par des équivalents utilisant le format glTF. Il ajoute " les primitives ne fonctionnes plus ? Achetez en de nouvelles ! "
  • Les piques humoristiques vont bon train pour exprimer des préoccupations sur les exigences matérielles et les performances liées à l'utilisation de glTF dans le viewer de Second Life, en particulier en ce qui concerne les ressources nécessaires pour faire fonctionner des graphismes avancés.

Quelques exemples

  • "Commencez à économiser pour acheter un 4090.": carte graphique NVIDIA GeForce RTX 4090
  • "Et un abonnement perpétuel à Substance Painter." : Substance Painter est un logiciel de texturage 3D qui nécessite un abonnement. Cette remarque suggère que les utilisateurs devront investir dans des outils coûteux pour créer des textures de haute qualité pour leurs modèles.
  • "Et une nouvelle climatisation pour la maison..."
  • "La région LBSA transforme mon PC en chauffage d'appoint."
  • "Il va falloir que ça marche aussi pour les mobiles, ça va faire exploser les téléphones partout."
  • "Il suffit de transporter une éolienne."

Viewer pour OpenSim

  • Tout le monde est d'accord pour dire qu'il faut qu'OpenSim ait sont propre viewer. Mais c'est un projet énorme qui demanderait des développeurs supplémentaires (8 personnes de plus).
  • Vincent Sylvester dit qu'il est temps d'apprendre le language Rust pour aider Joe Magarac à developper son viewer Sharpview. Sharpview a déjà trois ans d'expérience.
  • Mais Rust est en train de perdre ses points forts.
  • Orbert Tatham signale que Rust est le seul langage à mémoire sûre sans run time et garbage collection. Il ajoute bonne chance pour écrire un viewer dans n'importe quel autre langage.

CoolVL

NDLR  :

🏗️ Pour l'instant la fin est obscure ... .


Source

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

Récupérée de « https://cogito.no-ip.info/cogito/OSWiki/index.php?title=Réunion_du_06-08-2024&oldid=10064 »