Aller au contenu

« Réunion du 30-07-2024 » et « Réunion du 06-08-2024 » : différence entre les pages

De OSWiki
(Différence entre les pages)
Page créée avec « = Avertissement = {{Avertissement_résumé|fond=pink |bord=red |message = 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 [http://opensimulator.org/wiki/Office_hours réunions du mardi] ou sur [http://opensimulator.org/wiki/IRC le canal IRC]. Je ne fais pas partie des... »
 
Page créée avec « = Changements du code de la semaine= == Références nulles == *[http://opensimulator.org/viewgit/?a=commit&p=opensim&h=f1b6d9186e26d4219bf13f7f972c378de895e5b5 Commit f1b6d9] et [http://opensimulator.org/viewgit/?a=commit&p=opensim&h=70fa48280cd0fe93dff10537aec75d2ac7db4fb3 Commit 70fa48]: solutions de contournement pour certaines '''références nulles'''. [http://opensimulator.org/mantis/view.php?id=9135 Mantis 9135] == Temps de calcul CPU == *[http://opensim... »
 
Ligne 1 : Ligne 1 :
= Changements du code de la semaine=
== Références nulles ==
*[http://opensimulator.org/viewgit/?a=commit&p=opensim&h=f1b6d9186e26d4219bf13f7f972c378de895e5b5 Commit f1b6d9] et [http://opensimulator.org/viewgit/?a=commit&p=opensim&h=70fa48280cd0fe93dff10537aec75d2ac7db4fb3 Commit 70fa48]: solutions de contournement pour certaines '''références nulles'''. [http://opensimulator.org/mantis/view.php?id=9135 Mantis 9135]
== Temps de calcul CPU ==
*[http://opensimulator.org/viewgit/?a=commit&p=opensim&h=d9cfb3bcae4365bb1a20652d4465a25f6db191d7 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 =
= Avertissement =
{{Avertissement_résumé|fond=pink |bord=red |message = 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 [http://opensimulator.org/wiki/Office_hours réunions du mardi] ou  sur [http://opensimulator.org/wiki/IRC le canal IRC]. Je ne fais pas partie des développeurs, ne vous adressez pas à moi pour les joindre. Merci.😉}}
{{Avertissement_résumé|fond=pink |bord=red |message = 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 [http://opensimulator.org/wiki/Office_hours réunions du mardi] ou  sur [http://opensimulator.org/wiki/IRC le canal IRC]. Je ne fais pas partie des développeurs, ne vous adressez pas à moi pour les joindre. Merci.😉}}
= Heightmap =
= Modules =
==Chargeur de terrain Tiff==
==Optimisation de la génération des carreaux de carte==
* [[Réunion_du_23-07-2024#Chargeur_de_terrain_Tiff| '''Présentation du chargeur Tiff pendant la réunion du 23 juillet 2024''']]
* Il y a plusieurs mois Vincent Sylvester avait commencé à optimiser le code de génération des [[Lexique_des_réunions#Maptile|'''maptiles''']], il avait déplacé la plupart des tâches de génération dans un [[Lexique_des_réunions#Thread|'''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é.  
* Vincent Sylvester a implémenté les niveaux de gris 16 bits. Cela signifie que chaque pixel peut avoir 2^16 (soit 65 536) valeurs différentes. La commande '''terrain save-tile''' vérifie toujours la profondeur de bits et utilise ce qui est trouvé, donc supporte également les anciens 8 bits, mais pour le TIFF, il sauvegardera les nouveaux fichiers en 16 bits, ce qui permet un terrain de 4096 en hauteur au cas où on en aurait besoin.
* 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.
* Il faut encore nettoyer un peu le code et le tester pour voir si le chargement est robuste. Dans l'ensemble, ça avance. Il faut faire plus de tests et corriger les erreurs, mais c'est mieux que d'essayer de trouver comment convertir  RAW32.  
* Amélioration supplémentaire avec le [[Lexique_des_réunions#Maptile|'''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.
* TIFF 16 bits peut être chargé dans '''Gimp''' sans aucun plugin, il supporte nativement ce type et peut également être sauvegardé dans ce format. Cela signifie que convertir des heightmaps existantes en TIFF et charger de hautes montagnes devient  plus facile.
* Résultat, il a pu générer  5085 tuiles de niveau de zoom  pour 13056 carreaux de carte en seulement 144,23 secondes.
* La résolution verticale de la heightmap  va affecter la qualité et le niveau de détail du terrain. Les niveaux de gris de 16 bits permettent une grande précision. Vincent Sylvester a réduit les niveaux de gris à 4096 pour faciliter la visualisation puisque le traitement de l'image ne nécessite pas la pleine gamme de 65 536 niveaux.
* 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.
* Conversion (du niveau de gris ?) en hauteur (ndlr : j'indique la ligne de code ici mais je n'en sais pas plus).  
* 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.
(ushort)((valeur - minHeight) * 65535 / (maxHeight - minHeight)) ;
La valeur est décalé de 256 mètres vers le haut, donc le terrain à la limite inférieure de -100 ne devrait pas être traité.
* La sauvegarde et le chargement n'entraînent aucune modification de l'aspect du terrain.


== Ajout d'une commande terrain save-tile-ext  ==
= Viewers=
=== Le problème de sauvegarde des heightmap ===
== Viewer Dayturn ==
* On peut charger un terrain avec un déplacement mais , on ne peut pas l'enregistrer avec un déplacement. On ne peut pas non plus enregistrer une région plus grande dans un fichier plus petit. Supposons qu'on  veuille diviser une région  6x6  en 2x2, on  ne peut le faire qu'au chargement, ce qui peut être gênant.
* Pas beaucoup d'évolution depuis quelques semaines, ajout d'un peu de code et nettoyage.
{{NDLR|fond=white |bord=green|message = <br>
* La base du code Liden Lab devient de plus difficile à suivre.
* Une région 6x6 correspond à une région de 256*6 x 256 * 6, c'est à dire 1536x1536. C'est la même chose pour une région 2x2 qui correspond à une région 512x512.
* Je pense que l'idée de sauvegarder un terrain pour une autre dimension / agencement est une bonne idée. Ainsi, il est plus simple d'enregistrer plusieurs versions d'un terrain au moment de sa création, en les nommant en fonction des caractéristiques de chaque sauvegarde, plutôt que de se compliquer la vie plus tard en essayant de se souvenir pourquoi, comment et où nous avons utilisé la heightmap. Ensuite, il faudrait charger l'OAR et risquer de se tromper plusieurs fois avant d'obtenir le résultat souhaité.
}}
 
=== La commande '''terrain save-tile'''===
* Cette commande existe  déjà. Elle enregistre une heightmap dans un fichier plus grand. L'exemple donné au début de la réunion par Vincent Sylvester  concerne cette commande :
terrain save-tile <nom_du_fichier> 3 3 999 999
Ici on sauvegarde une région de taille 256 aux coordonnées 999,999 au centre d'un fichier 768x768 pixels de coordonnées 1000x1000, on décale la région d'un point en diagonale.  Il n'y a aucun moyen de sauvegarder cette même région au centre d'une image de 512 pixels, parce que le système est basé sur les tuiles et non sur les mètres. Une tuile correspond à la taille d'une région, quelle que soit cette taille, donc si la région a une taille de 768, il en sera de même pour chaque tuile. Comme tout est basé sur la taille de la région, cela signifie qu'il n'est pas possible de sauvegarder un fichier de 256 dans une image de  512 et le décaler pour que l'île soit au milieu parce que la plus petite tuile est 256.
<pre>
terrain save-tile
Sauvegarde la heightmap actuelle dans un fichier le plus grand.
= Paramètres =
* filename (Chaîne)
        Le fichier dans lequel vous souhaitez enregistrer, l'extension du fichier détermine le chargeur à utiliser. Les extensions prises en charge sont les suivantes .png (PNG)
* Largeur du fichier (Entier)
        La largeur du fichier en carreaux (un carreau a la taille de la région)
* Hauteur du fichier (Entier)
        La hauteur du fichier en carreaux (un carreau a la taille de la région)
* tuile X minimale (Entier)
        La coordonnée X de la région de la première tuile du fichier.
* tuile Y minimale (Entier)
        Les coordonnées Y de la région de la première tuile du fichier.
= Exemple =
Pour enregistrer un fichier PNG pour un ensemble de tuiles de carte de 3 régions de large et 3 régions de haut à partir des coordonnées de la carte (9910,10234)
        # terrain save-tile ST06.png 3 3 9910 10234
</pre>


=== La commande terrain save-tile-ext ===
== Problèmes liés au récentes modifications de Second Life ==
* La commande ajoutée par Vincent Sylvester '''terrain save-tile-ext''', permet d'indiquer la taille du fichier en pixels / mètres, le décalage et la partie de la région à sauvegarder si par exemple on veut diviser une région de 512 en 4 plus petites.
=== Second Life ===
* Prototype de la fonction dans le code OpenSim :
* 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 [[Lexique_des_réunions#PBR | PBR]] alors qu'il suffit de désactiver une option.
SaveFile(ITerrainChannel map, string filename, int fileWidth, int fileHeight, int startX, int startY, int stopX, int stopY, int offsetX, int offsetY).
* Beaucoup de gens sur les groupes de Firestorm demandent de '''désactiver PBR'''. [[Lexique_des_réunions#Viewer_Coll_VL |'''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.
{{NDLR|fond=white |bord=green|message = <br>
* Mais Liden Lab va probablement rendre [[Lexique_des_réunions#PBR | '''PBR''']] obligatoire à cause du '''viewer mobile'''. Ils poussent tous les viewers tiers à passer à [[Lexique_des_réunions#PBR | '''PBR''']]et à [[Lexique_des_réunions#WebRTC |'''WebRTC''']] rapidement. Ils sont forcés par les investisseurs. Il semble que Liden Lab dépensent beaucoup de dollars, ils embauchent beaucoup de codeurs.
La commande de console devrait être appelée ainsi (c'est une déduction et pas une certitude ) :
* Liden Lab semble également envisager de revenir à baking côté viewer. Ils auraient trop de charge sur les systèmes de gestion de données.
<pre>
terrain save-tile-ext fileName fileWidth fileHeight startX startY stopX stopY offsetX offsetY
Paramètres :
* filename (Chaîne)
        Fichier enregistré. Il s'agit du nom du fichier dans lequel la heightmap sera sauvegardée.
* fileWidth (entier)
        Largeur du fichier de sortie en  pixels. Cela détermine la largeur de l'image qui sera générée à partir de la zone du terrain spécifiée.
* fileHeight (entier)
        Hauteur du fichier de sortie en pixels. Cela détermine la hauteur de l'image qui sera générée à partir de la zone du terrain spécifiée.
* startX (entier)
        Coordonnée X du coin inférieur gauche de la zone à sauvegarder. Cela représente la position horizontale de départ dans le terrain, avec l'origine située en bas à gauche.
* startY (entier) 
        Coordonnée Y du coin inférieur gauche de la zone à sauvegarder. Cela représente la position verticale de départ dans le terrain, avec l'origine située en bas à gauche.
* stoptX (entier)
        Coordonnée X du coin supérieur droit  de la zone à sauvegarder. Cela représente la position horizontale de fin dans le terrain.
* stopY (entier)
        Coordonnée Y du coin supérieur droit de la zone à sauvegarder. Cela représente la position verticale de fin dans le terrain.
* offsetX (entier)
        Décalage horizontal à appliquer lors de la sauvegarde. Cela peut être utilisé pour ajuster la position de la zone sauvegardée par rapport à l'origine.
* offsetY (entier)
        Décalage vertical à appliquer lors de la sauvegarde. Cela peut être utilisé pour ajuster la position de la zone sauvegardée par rapport à l'origine.  


Exemple : sauvegarder une région de 256x256 au centre d'une heightmap de 512x512 (à vérifier ne prenez pas cela pour argent comptant !).
=== Firestorm et OpenSim ===
  terrain save-tile-ext "mon_image.png" 512 512 0 0 256 256 128 128 
* '''Problèmes avec PBR''' : Depuis vendredi, il était impossible d'utiliser une version fonctionnelle de Firestorm avec PBR dans OpenSimulator.
</pre>
* 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 ([[Lexique_des_réunions#BOM |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.


== Commande pour charger et déplacer un terrain ==
=== Migrations vers OpenSim ? ===
* Ubit Umarov  trouve que '''terrain save-tile-ext''' n'est pas utile et qu'il existe déjà des options  pour charger et déplacer le terrain d'une région. Dans '''terrain save-tile''' les coordonnées globales n'ont pas d'importance. Les heigmaps ont 0,0 au coin inférieur gauche normal, le point de référence pour une région. Le seul problème est que pour importer, il faut connaître la taille de la région et  avoir quelques connaissances en mathématiques.  
* 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 ?
<pre>
* C'est possible mais,  il existe quelques raisons qui ne le permettent pas.
load oar [-m|--merge] [-s|--skip-assets] [--default-user "Nom d'utilisateur"] [--merge-terrain] [--merge-parcels] [--mergeReplaceObjects] [--no-objects] [--rotation degrés] [--bounding-origin "<x,y,z>"] [--bounding-size "<x,y,z>"] [--displacement "<x,y,z>"] [-d|--debug] [<chemin OAR>]
<ul>
<li>Certains sont tout simplement '''trop investis'''. Une chose est de déplacer votre présence, une autre de déplacer toutes vos affaires.</li>
<li>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.</li>
<li>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'''.</li>
<li></li>
</ul>


Charge les données d'une région à partir d'une archive OAR.
===Importation de mesh depuis SL vers OpenSim ===
* La dernière fois qu' orbert tatham  a essayé d'importer [[Lexique_des_réunions#Mesh |'''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.


    --merge : fusionne l'OAR avec la scène existante (supprime le chargement des informations sur le terrain et les parcelles).
===Utilisation de glTF ===
        Options avec --merge :
* '''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 ?
            --merge-terrain : charge également le terrain, remplaçant l'original.
* 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 ! "
            --merge-parcels : charge également les parcelles, en les fusionnant avec l'original.
* 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.
            --mergeReplaceObjects : si la scène contient un objet avec le même identifiant, le remplace. Sans cette option, le chargement de cet objet est ignoré.
    --skip-assets : charge l'OAR mais ignore les ressources qu'il contient.
    --default-user : utilise cet utilisateur pour tout objet dont le propriétaire a un UUID non trouvé dans la grille.
    --no-objects : supprime l'ajout de tout objet (utile pour charger uniquement le terrain).
    --rotation : spécifie la rotation à appliquer à l'OAR. Spécifiée en degrés.
    --bounding-origin : ne placera que les objets qui, après déplacement et rotation, tombent dans le cube englobant dont la position commence à <x,y,z>. Par défaut, c'est <0,0,0>.
    --bounding-size : spécifie la taille du cube englobant. La valeur par défaut est la taille de la région de destination et ne peut pas être plus grande que cela.
    --displacement : ajoutera cette valeur à la position de chaque objet chargé.
    --debug : force l'archiver à afficher des messages sur l'emplacement de chaque objet.


Le chemin peut être soit un emplacement sur le système de fichiers, soit une URI. Si cela n'est pas spécifié, la commande recherche un OAR nommé region.oar dans le répertoire courant. [--rotation-center "<x,y,z>"] était une option, mais elle ne fait plus rien et sera bientôt supprimée.
'''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."'''


Lorsqu'un OAR est chargé, les opérations sont appliquées dans cet ordre :
===Un 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[https://fr.wikipedia.org/wiki/Rust_(langage)] pour aider Joe Magarac à developper son viewer [[Lexique_des_réunions#Viewer_Sharpview |'''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 runtime [https://fr.wikipedia.org/wiki/Environnement_d%27ex%C3%A9cution] et garbage collection[https://fr.wikipedia.org/wiki/Ramasse-miettes_(informatique)]. Il ajoute bonne chance pour écrire un viewer dans n'importe quel autre langage.


    Rotation (autour du centre de la région de l'OAR entrant)
==Viewer CoolVL ==
    Découpage (un cube englobant avec origine et taille)
* [[Lexique_des_réunions#Viewer_Coll_VL|Cool VL]] viewer développé en C++ pour Linux/Mac/Win. Branche du viewer de SL V1.
    Déplacement (définir les coordonnées de décalage dans la région de destination)
* Henri Beauchamp a ajouté le terrain [[Lexique_des_réunions#PBR | PBR]]
</pre>
* La version Mac semble mal fonctionner d'après Gavin Hirt.  
 
* Ubit Umarov dit que Cool VL a consommé 250 W sur la région Ubittest2 alors que Firestorm en a consommé 120 mais il faut dire que Cool VL fait 140 fps et firestorme 30fps.
= Viewers=
== Sharpview ==
* '''Nouvelle version de Sharpview''' qui permet d'obtenir des jonctions correctes entre les régions. https://animats.com/sharpview/releases/release-0.9.0.html. Si vous trouvez des régions qui n'ont pas de jonctions correctes, faites-le savoir à Joe Magarac.
== Divers ==
* Certains viewers ont du mal à gérer les régions de 768x768. Plusieurs ne fonctionnent qu'avec des tailles qui sont des puissances de 2 comme 256, 512, 1024, 2048.


= Source=
= Source=
http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2024-07-30
http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2024-08-06

Dernière version du 30 novembre 2024 à 16:03

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.
  • Liden Lab semble également envisager de revenir à baking côté viewer. Ils auraient trop de charge sur les systèmes de gestion de données.

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

Un 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[1] 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 runtime [2] et garbage collection[3]. Il ajoute bonne chance pour écrire un viewer dans n'importe quel autre langage.

Viewer CoolVL

  • Cool VL viewer développé en C++ pour Linux/Mac/Win. Branche du viewer de SL V1.
  • Henri Beauchamp a ajouté le terrain PBR
  • La version Mac semble mal fonctionner d'après Gavin Hirt.
  • Ubit Umarov dit que Cool VL a consommé 250 W sur la région Ubittest2 alors que Firestorm en a consommé 120 mais il faut dire que Cool VL fait 140 fps et firestorme 30fps.

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_30-07-2024&oldid=253 »