« Réunion du 06-08-2024 » : différence entre les versions
Aller à la navigation
Aller à la recherche
(→Suite) |
|||
Ligne 38 : | Ligne 38 : | ||
=== Migrations vers OpenSim ? === | === 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 premettent pas. | |||
<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 de choses qu'ils ont achetées.</li> | |||
<li></li> | |||
</ul> | |||
===Suite === | ===Suite === |
Version du 9 août 2024 à 04:19
Changements du code de la semaine
Références nulles
- Commit f1b6d9 et Commit 70fa48: solutions de contournement pour certaines références nulles. Mantis 9135
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 avec PBR
Second Life
- Sur certains forum 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 au pbr et au 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 premettent 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 de choses qu'ils ont achetées.
Suite
- Difficultés de passer de SL à OpenSim
- Importation de meshes
- GLTF
- Viewer pour OpenSim
NDLR : 🏗️ Pour l'instant la fin est obscure ... . |
Source
http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2024-08-06