« Réunion du 25-06-2024 » : différence entre les versions
Aller à la navigation
Aller à la recherche
| (24 versions intermédiaires par le même utilisateur non affichées) | |||
| Ligne 1 : | Ligne 1 : | ||
= Changements du code de la semaine= | = Changements du code de la semaine= | ||
| Ligne 29 : | Ligne 22 : | ||
= 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.😉}} | ||
= | = Questions = | ||
== TPs d'une petite grille ne fonctionnent plus == | |||
== TPs d'une | |||
=== Le problèmes === | === Le problèmes === | ||
*Kayaker Magic a une petite grille qui fonctionnait bien pendant des mois. Maintenant, '''les téléportations région à région ne fonctionnent plus de façon intermittente'''. | *Kayaker Magic a une petite grille qui fonctionnait bien pendant des mois. Maintenant, '''les téléportations région à région ne fonctionnent plus de façon intermittente'''. | ||
| Ligne 45 : | Ligne 34 : | ||
* Différentes instances d'OpenSim sur le même serveur et même nom d'hôte. | * Différentes instances d'OpenSim sur le même serveur et même nom d'hôte. | ||
* Seulement 25% de la mémoire est utilisée et rien d'autre n'utilise le réseau. | * Seulement 25% de la mémoire est utilisée et rien d'autre n'utilise le réseau. | ||
* '''Le redémarrage du serveur n'a pas résolu le problème.''' | |||
* Le(s) processeur·s semble(nt) très occupé·s, certaines instances en utilisent beaucoup trop... | |||
* Utilisation de Mono | |||
=== Réponse === | === Réponse === | ||
| Ligne 50 : | Ligne 42 : | ||
* La mise à jour de l'agent dépend de HTTP | * La mise à jour de l'agent dépend de HTTP | ||
= | == Téléchargement de meshes == | ||
= | === Problème === | ||
* La question est posée par Cuga.Rajal. Quand il '''télécharge un grand mesh''', il analyse les coques (synonymes : "hulls", "shells", "bounding volumes" ou "volumes englobants"). s'il ne trouve pas d'erreur, il télécharge le mesh sur OpenSim. L'analyse dans le viewer fonctionne. À ce moment il clique sur le bouton "Télécharger (Upload)". Parfois il obtient un message d'erreur '''"File Not Found"'''. Parfois il doit redémarrer le viewer après un échec. Il demande comment résoudre le problème ? Y a-t-il un GC (Ramasse-miettes [https://fr.wikipedia.org/wiki/Garbage_collector])qui supprime le modèle s'il prend trop de temps ? | |||
=== Réponses === | |||
* Ubit Umarov répond que '''le code des viewers pour analyser les coques est mauvais'''. Les développeurs du viewer de Second Life utilisent des outils de maillage de type Havoc [https://fr.wikipedia.org/wiki/Havok_(entreprise)]. Pour Opensim ils utilisent une librairie opensource mais son intégration est médiocre. | |||
* Les viewers n'ont pas de '''GC'''. | |||
* '''Ubit Umarov''' indique qu'on nous a toujours dit de '''ne pas utiliser d'analyse sur les viewers pour OpenSim'''. En fait, '''UbODe''' n'utilise même pas les coques convexes. '''BulletSim''' essaye de faire des coques. | |||
= Viewers= | = Viewers= | ||
==Test de la nouvelle version du viewer Firestorm == | ==Test de la nouvelle version du viewer Firestorm == | ||
| Ligne 66 : | Ligne 65 : | ||
* L''''occlusion d'objet''' est aussi cassées. Ceci dit, l'élimination des occlusions est difficile dans un système avec autant de transparences. Dans peu de jeux, on peut regarder à l'intérieur d'un bâtiment par une fenêtre et voir de l'autre côté par une autre fenêtre. | * L''''occlusion d'objet''' est aussi cassées. Ceci dit, l'élimination des occlusions est difficile dans un système avec autant de transparences. Dans peu de jeux, on peut regarder à l'intérieur d'un bâtiment par une fenêtre et voir de l'autre côté par une autre fenêtre. | ||
{{NDLR|fond=white |bord= green|message = | {{NDLR|fond=white |bord= green|message = | ||
L' | L'occlusion d'objet est une technique utilisée dans les environnements 3D pour déterminer quels objets ne sont pas visibles pour la caméra à un moment donné et peuvent donc être omis du processus de rendu pour économiser des ressources. | ||
}} | }} | ||
* '''Le calcul des ombres''' pose aussi des problèmes. Si on place un objet à deux fois la distance de vue, il est toujours pris en compte pour le calcul des ombres. | * '''Le calcul des ombres''' pose aussi des problèmes. Si on place un objet à deux fois la distance de vue, il est toujours pris en compte pour le calcul des ombres. | ||
| Ligne 73 : | Ligne 72 : | ||
Une sonde est un élément virtuel utilisé pour capturer les informations sur l'environnement environnant et les refléter de manière réaliste dans un miroir virtuel. | Une sonde est un élément virtuel utilisé pour capturer les informations sur l'environnement environnant et les refléter de manière réaliste dans un miroir virtuel. | ||
Il est | Il est capital de placer la sonde de manière précise pour garantir des reflets dans le miroir correct et cohérents avec l'environnement virtuel. Des erreurs ou des imprécisions dans la position ou l'orientation de la sonde pourraient entraîner des artefacts visuels ou des distorsions dans le rendu des miroirs, affectant ainsi la qualité globale de l'expérience visuelle | ||
}} | }} | ||
| Ligne 82 : | Ligne 81 : | ||
=== RenderSkyAutoAdjustProbeAmbiance=== | === RenderSkyAutoAdjustProbeAmbiance=== | ||
* Si on met l'option de débogage '''"RenderSkyAutoAdjustProbeAmbiance" à 0''', le rendu d'EEP ressemble beaucoup plus à celui des anciens viewers. AutoAdjust semble être une catastrophe. Les utilisateurs de Second Life se plaignent que EEP commence à envoyer trop de lumière. Hors la plupart du temps il | * Si on met l'option de débogage '''"RenderSkyAutoAdjustProbeAmbiance" à 0''', le rendu d'EEP ressemble beaucoup plus à celui des anciens viewers. AutoAdjust semble être une catastrophe. Les utilisateurs de Second Life se plaignent que EEP commence à envoyer trop de lumière. Hors la plupart du temps il s’agit d'un "réglage automatique". On dirait que cela ne tient pas compte du fait que la lumière était '''sRGB''' et qu'elle est maintenant linéaire. | ||
{{NDLR|fond=white |bord= green|message = | |||
'''L'espace colorimétrique sRGB''' est conçu pour correspondre de manière plus étroite à la façon dont les couleurs sont perçues par l'œil humain, ce qui le rend idéal pour l'affichage sur des écrans. En revanche, '''l'espace colorimétrique linéair'''e est une représentation plus précise des couleurs telles qu'elles sont réellement, sans ajustements pour la perception humaine.Elle peut permettre une plus grande précision, un contrôle de l'éclairage plus réaliste, une compatibilité avec d'autres logiciels, un ajustement artistique plus fin. | |||
}} | |||
{{NDLR|fond=white |bord= green|message = | {{NDLR|fond=white |bord= green|message = | ||
''' | <br> | ||
* L'option de débogage '''"RenderSkyAutoAdjustProbeAmbiance"''' n'existe que dans la nouvelle version de Firestorm (version 7.x). Par défaut elle est définie à '''0.010'''. | |||
* Vous trouverez des indications pour ouvrir la fenêtre des options de débogage [[Lexique_des_réunions#Afficher_les_paramètres_de_débogage|'''sur cette page''']] | |||
* Si vous modifiez ce paramètre, vous serez seul·e à voir les modifications. | |||
}} | }} | ||
* | * Quelqu’un s'est plaint qu'une '''région était sombre après avoir installé une skybox''' à 2000 mètres et réglé la distance de vue à 1024. Ubit Umarov conseille de mettre "RenderSkyAutoAdjustProbeAmbiance" à 0. Il n'a aucune idée de ce que cet ajustement automatique est supposé faire, mais il semble mal le faire dans plusieurs situations. | ||
= Source= | = Source= | ||
http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2024-06-25 | http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2024-06-25 | ||
Dernière version du 9 juillet 2024 à 09:21
Changements du code de la semaine
Patch de BlueWall pour PostgreSQL
- Commit ebcc0f : Corrections PostrgreSQL : stockage des régions, liste muette et un gestionnaire de table générique
- Commit 6c857b : Correction d'une mauvaise clé primaire sur les points de chute du téléhub. Le RegionUUID étant créé en tant que clé primaire unique, un seul point de connexion pouvait être créé. La clé primaire a été remplacée par une clé utilisant plusieurs colonnes afin de garantir que chaque point de chute occupe un espace unique dans la région.
- Commit eb74fa : Correction du chargement des données de la région afin d'éviter la suppression des points d'arrivée du téléhub.
- Commit 48a300 : Ajout de la table 'regionextra' manquante et des gestionnaires associés à l'adaptateur PostrgreSQL.
Ajout de llDerezObject
- Commit cc1227 [1]
- Prototype
integer llDerezObject( key id, integer flag );
- llDerezObject [2] permet à un objet rezzeur de supprimer les objets qu'il a rezzé ou de les rendre temporaires pour une suppression différée.
llSetCameraAtOffset() ou llSetCameraEyeOffset() et primitive racine
- Commit c4635d [3] : llSetCameraAtOffset() ou llSetCameraEyeOffset() sur une primitive enfant ne perturbe plus la primitive racine ( reverts 174df941720bc45c1e73224919c34f059129b9e1)
- llSetCameraAtOffset()[4] et llSetCameraEyeOffset()[5] dans une primitive enfant modifiait la primitive racine si elle n'avait pas de valeur définie. L'ancien message de commit disait que c'était pour correspondre à Second Life. Si c'était le cas alors, c'était un bogue de SL corrigé depuis longtemps.
Correction pour le terrain PBR
- Commit 583cc0 [6] : ajout d'une chaîne uuid zéro par défaut aux entrées PBR pour MySQL et PostrgreSQL.
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.😉 |
Questions
TPs d'une petite grille ne fonctionnent plus
Le problèmes
- Kayaker Magic a une petite grille qui fonctionnait bien pendant des mois. Maintenant, les téléportations région à région ne fonctionnent plus de façon intermittente.
- Les utilisateurs se connectent depuis différents points du pays, donc les fournisseurs d'accès locaux ne peuvent pas être en cause.
- La console montre l'arrivée de l'avatar, puis elle s'éteint avant d'avoir terminé.
11:44:20 - [SCENE] : Incoming child agent update for 65ca4ec1-6581-45f6-918b-adbe66917db2 in Maritime 14 11:44:28 - [SCENE PRESENCE] : Update agent Kayaker Magic at Maritime 14 did not receive agent update 11:47:15 - [AGENT HANDLER] : >>> DELETE
- Un TP au même endroit plusieurs fois finit par marcher.
- Différentes instances d'OpenSim sur le même serveur et même nom d'hôte.
- Seulement 25% de la mémoire est utilisée et rien d'autre n'utilise le réseau.
- Le redémarrage du serveur n'a pas résolu le problème.
- Le(s) processeur·s semble(nt) très occupé·s, certaines instances en utilisent beaucoup trop...
- Utilisation de Mono
Réponse
- Latence (lag) [7] ou échec de HTTP.
- La mise à jour de l'agent dépend de HTTP
Téléchargement de meshes
Problème
- La question est posée par Cuga.Rajal. Quand il télécharge un grand mesh, il analyse les coques (synonymes : "hulls", "shells", "bounding volumes" ou "volumes englobants"). s'il ne trouve pas d'erreur, il télécharge le mesh sur OpenSim. L'analyse dans le viewer fonctionne. À ce moment il clique sur le bouton "Télécharger (Upload)". Parfois il obtient un message d'erreur "File Not Found". Parfois il doit redémarrer le viewer après un échec. Il demande comment résoudre le problème ? Y a-t-il un GC (Ramasse-miettes [8])qui supprime le modèle s'il prend trop de temps ?
Réponses
- Ubit Umarov répond que le code des viewers pour analyser les coques est mauvais. Les développeurs du viewer de Second Life utilisent des outils de maillage de type Havoc [9]. Pour Opensim ils utilisent une librairie opensource mais son intégration est médiocre.
- Les viewers n'ont pas de GC.
- Ubit Umarov indique qu'on nous a toujours dit de ne pas utiliser d'analyse sur les viewers pour OpenSim. En fait, UbODe n'utilise même pas les coques convexes. BulletSim essaye de faire des coques.
Viewers
Test de la nouvelle version du viewer Firestorm
- Sortie de la version PBR 7.1.9 (74745) [10], il semble d'après l'avis général que cette version n'est pas optimale.
Les problèmes
- Dans OpenSim il y a plus de crash que dans Second Life spécialement si le cache est vide.
- Crash également sur la téléportation.
- Régressions des performances du viewer pour des effets de textures qui ne sont pas extraordinaires.
- Un utilisateur de Second Life doit disposer d'un matériel informatique encore plus performant qu'un utilisateur de Steam car la plupart des jeux sur Steam ont besoin de moins de GPU pour beaucoup plus de contenu PBR. Une metavers créé par l'utilisateur nécessite environ trois fois plus de mémoire GPU qu'un jeu bien optimisé.
- Le moteur de rendu PBR effectue la majeure partie du travail dans le GPU. Avec un GPU de niveau joueur, c'est génial sinon, c'est horrible.
- Le moteur de rendu des viewers ne sont pas assez performants. Il faudrait développer un meilleur moteur de rendu.
- PBR fait beaucoup de mal à l'environnement EEP.
- La capacité à contrôler la quantité de détails des objets 3D, les LOD (Level of Detail ), en fonction de la distance d'affichage est gravement altérée ou dysfonctionnelle.
- L'occlusion d'objet est aussi cassées. Ceci dit, l'élimination des occlusions est difficile dans un système avec autant de transparences. Dans peu de jeux, on peut regarder à l'intérieur d'un bâtiment par une fenêtre et voir de l'autre côté par une autre fenêtre.
| NDLR : L'occlusion d'objet est une technique utilisée dans les environnements 3D pour déterminer quels objets ne sont pas visibles pour la caméra à un moment donné et peuvent donc être omis du processus de rendu pour économiser des ressources. |
- Le calcul des ombres pose aussi des problèmes. Si on place un objet à deux fois la distance de vue, il est toujours pris en compte pour le calcul des ombres.
- Les miroirs posent aussi des problèmes. La position de la sonde est très critique, il peut y avoir des artefacts. Dans certains cas plus de 1Go d'utilisation supplémentaire de VRAM.[11]
| NDLR : Une sonde est un élément virtuel utilisé pour capturer les informations sur l'environnement environnant et les refléter de manière réaliste dans un miroir virtuel.
Il est capital de placer la sonde de manière précise pour garantir des reflets dans le miroir correct et cohérents avec l'environnement virtuel. Des erreurs ou des imprécisions dans la position ou l'orientation de la sonde pourraient entraîner des artefacts visuels ou des distorsions dans le rendu des miroirs, affectant ainsi la qualité globale de l'expérience visuelle |
Problèmes pour les utilisateurs de Second Life
- Les utilisateurs de Second Life sont mécontents de l'augmentation des besoins en matériel pour PBR.
Causes des problèmes PBR
- Second Life s'est précipité pour sortir la nouvelle version de son viewer pour la fête de son 21e anniversaire SL21B. Ce viewer contient les nouvelles fonctionnalités PBR et terrain PBR. Ainsi, les viewers tiers comme Firestorm ont été forcés de sortir aussi une nouvelle version.
RenderSkyAutoAdjustProbeAmbiance
- Si on met l'option de débogage "RenderSkyAutoAdjustProbeAmbiance" à 0, le rendu d'EEP ressemble beaucoup plus à celui des anciens viewers. AutoAdjust semble être une catastrophe. Les utilisateurs de Second Life se plaignent que EEP commence à envoyer trop de lumière. Hors la plupart du temps il s’agit d'un "réglage automatique". On dirait que cela ne tient pas compte du fait que la lumière était sRGB et qu'elle est maintenant linéaire.
| NDLR : L'espace colorimétrique sRGB est conçu pour correspondre de manière plus étroite à la façon dont les couleurs sont perçues par l'œil humain, ce qui le rend idéal pour l'affichage sur des écrans. En revanche, l'espace colorimétrique linéaire est une représentation plus précise des couleurs telles qu'elles sont réellement, sans ajustements pour la perception humaine.Elle peut permettre une plus grande précision, un contrôle de l'éclairage plus réaliste, une compatibilité avec d'autres logiciels, un ajustement artistique plus fin. |
NDLR :
|
- Quelqu’un s'est plaint qu'une région était sombre après avoir installé une skybox à 2000 mètres et réglé la distance de vue à 1024. Ubit Umarov conseille de mettre "RenderSkyAutoAdjustProbeAmbiance" à 0. Il n'a aucune idée de ce que cet ajustement automatique est supposé faire, mais il semble mal le faire dans plusieurs situations.
Source
http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2024-06-25