« Réunion du 01-10-2024 » : différence entre les versions
(58 versions intermédiaires par le même utilisateur non affichées) | |||
Ligne 3 : | Ligne 3 : | ||
= Noyau= | = Noyau= | ||
== Données liées à des grilles disparues == | == Données liées à des grilles disparues == | ||
=== Problème posé par Vincent Sylvester === | |||
* L'interconnexion entre les grilles permet de récupérer toutes sortes de données (surtout le nom des créateurs mais aussi des amis ou des groupes). Lorsqu'une grille disparaît, ces données pointent dans le vide ce qui peut provoquer '''une augmentation des délais de recherche des DNS'''. | |||
* La situation n'est pas aussi grave que ce que pouvait imaginer Vincent Sylvester, probablement en partie parce qu'il n'y a pas beaucoup de contenu en circulation. Dans le pire des cas, il y avait 15 000 échecs de DNS dans 50 régions à partir de plusieurs mois de données de log. | |||
* Pour tester les données cassées d'une région, on peut rechercher '''NameResolutionFailure''' dans le journal de la région (bin/OpenSim.log). | |||
* Le problème peut se révéler par exemple si de très nombreux assets de régions défuntes sont stockés sur une région. Certains propriétaires de grille "s'approprient" certains assets pour éliminer le délai DNS... ou pour "éliminer" d'autres choses... | |||
{{NDLR|fond=white |bord=green|message = <br> | |||
J'ai fait une recherche dans le log de la région Argentoratum sur la grille du même nom et j'obtiens les lignes suivantes : | |||
2024-05-09 21:47:18,619 DEBUG [USER AGENT CONNECTOR]: get_server_urls call to http://<Nom de domaine>:8002/ failed: Error: NameResolutionFailure | |||
2024-05-09 21:47:18,620 DEBUG [USER MANAGEMENT MODULE]: GetServerURLs call failed Error: NameResolutionFailure | |||
}} | |||
=== Solutions possibles === | |||
* '''Remplacer le nom de domaine''' lié à la donnée et la relier localement, mais cela a ses propres implications (NDLR : propriétaire, amis ou groupes inexistants, etc). | |||
* '''Utiliser une liste noire''' en interne si ces données erronées encombrent significativement une région, Mais il est difficile de garder une liste noire automatique d'échecs de DNS parce que les DNS échouent de temps en temps sur des choses valides. Il faudrait maintenir cette liste '''manuellement''' sur la base de la liste des grilles fermées connues. Mais, cela n'évitera pas le problème des standalones ou autres urls à courte durée de vie. | |||
* La configuration d'une liste noire pour chaque région serait très laborieux. '''Un service comme mutelist'''[http://opensimulator.org/wiki/MuteList][http://opensimulator.org/viewgit/?a=tree&p=opensim&h=44c6f83915287ffb10c98c743516f7f84207da7b&hb=54114a23f57dc464280423fe33654c19c374fe80&f=OpenSim/Services/MuteListService] serait peut-être plus efficace. Il serait possible d'utiliser une partie de ce code, ce serait une liste manuelle que Robust distribuerait aux régions. Robust pourrait même vérifier régulièrement si les liens sont vraiment morts et les régions demanderaient ces données une fois par jour. Ubit Umarov dit qu'à un moment donné, cette liste pourrait être aussi longue que le celle des assets. | |||
* Quand la recherche DNS échoue, aucune donnée factice de remplacement n'est envoyée. Cela pourrait être ajusté immédiatement en '''renvoyant un profil vide au viewer''' pour qu'il ne reste pas bloqué. ( D'ailleurs un certain nombre de processus pourraient voir leurs délais améliorés avec des valeurs par défaut de ce type). | |||
* Il faut également vérifier où des données potentiellement erronées sont '''mises en cache'''. | |||
==Problèmes hypergrid , est-ce la faute de dotnet ?== | ==Problèmes hypergrid , est-ce la faute de dotnet ?== | ||
=== Question === | |||
= | * Est-ce que le remplacement de [https://fr.wikipedia.org/wiki/Mono_(logiciel) '''Mono'''] par [[Lexique_des_réunions#dotnet | '''dotnet''']] est coupable de tous les problèmes que les gens rencontrent en hypergrid ? | ||
=== Réponse === | |||
* Les utilisateurs ont toujours eu des problèmes avec l'hypergrid. Il est plus probable que la cause réside dans des versions différentes du système d'exploitation entre la source et la destination, plutôt que dans des problèmes liés à dotnet et mono. | |||
* Cuga Rajal n'a pas de problème d'Hypergrid avec la version 0.9.3 d'OpenSim. En revanche, dans Osgrid, ce sont les régions qui fonctionnent avec d'anciennes versions qui lui poseraient des problèmes. | |||
= Modules= | |||
== Chat vocal : WebRTC et SSL== | |||
* [[Lexique_des_réunions#WebRTC |'''WebRTC''']] Requiert [https://fr.wikipedia.org/wiki/Transport_Layer_Security '''SSL''']. | |||
* [[Lexique_des_réunions#WebRTC |'''WebRTC''']] interdit les [https://fr.wikipedia.org/wiki/Certificat_autosign%C3%A9les '''certificats auto-signés''']. | |||
== Carte== | |||
=== Problème === | |||
* Web Rain a rencontré ce message dans la console : | |||
[WARNING]: EOC marker not found. Codestream is corrupted. | |||
=== Réponse=== | |||
* Ce message vient du moteur de rendu maptile, on peut l'ignorer. | |||
= Bugs = | = Bugs = | ||
==Déclenchement d'object_rez == | |||
* [http://opensimulator.org/mantis/view.php?id=9165 '''Mantis 0009165'''] : object_rez n'est pas déclenché avant la fin de state_entry() | |||
* Ce n'est pas un bug, c'est un comportement attendu. | |||
* Erreur dans le titre du rapport de bug il faut lire object_rez à la place de on_rez. | |||
{{NDLR|fond=white |bord=green|message = <br> | |||
'''Fonctions et événements LSL utilisés ''' | |||
* [https://wiki.secondlife.com/wiki/State_entry '''state_entry()''']] : évènement déclenché lors de toute transition d'état et lors du démarrage d'un script. | |||
* [https://wiki.secondlife.com/wiki/Object_rez/fr '''object_rez( key id ){ ; }'''] : évènement déclenché lorsque q'un objet rez un autre objet qui est dans son inventaire. | |||
* [https://wiki.secondlife.com/wiki/LlRezAtRoot '''llRezAtRoot( string inventory, vector position, vector velocity, rotation rot, integer param );'''] : Crée (rez) l'objet d'inventaire avec sa prim racine à la position '''pos''', avec la vitesse '''vit''', la rotation rot et les paramètres de départ '''param.''' | |||
'''Représentation schématique du problème''' (c'est comme cela que je me le représente... ) | |||
[[Fichier:Object rez.jpg|thumb|left]] | |||
}} | |||
* '''Explication d'Ubit Umarov dans les commentaires de la Mantis''' | |||
** Les événements d'un script sont exécutés un à la fois , par ordre d'arrivée dans la file d'attente (Ndlr : ici state_entry puis object_rez). Donc, object_rez(key id) ne sera exécuté qu'après avoir quitté state_entry() et après tout autre événement ayant atteint la file d'attente avant lui. | |||
** llRezAtRoot fonctionne de manière asynchrone, c'est-à-dire qu'il y a un thread pour A et un autre pour B, et donc B peut se terminer avant A. Il n'y a pas de relation temporelle entre le rez et l'événement object_rez(key id). | |||
* Dans les commentaires de la Mantis, JeffKelley propose un '''script pour contourner le problème'''. | |||
== LI dans opensim est juste indicatif == | |||
{{NDLR|fond=white |bord=green|message = <br> | |||
Il faudrait faire des tests dans le viewer, je ne sais pas à quoi correspond LI. ... J'y reviendrai peut-être. | |||
}} | |||
* Cuga Rajal a un mesh 1-LI qu'il relie à un cylindre plat régulier 1-LI. | |||
* Quand les deux objets (mesh + cylindre) sont liés, le viewer indique que l'objet lié contient 30-LI (30 liens/objets ?) . Quand le mesh et le cylindre sont déliés, l'ensemble revient à 2-LI. Cela, même si le mesh est sur Physics Type None. | |||
* Dans Blender le mesh était composé de 30 objets que Cuga Rajal a joints pour n'en faire plus qu'un. Il a optimisé le mesh puis l'a exporté et importé avec une forme physique de cube. | |||
* Ubit Umarov dit que LI dans OpenSim est indicatif. Les primitives sans mesh ont un LI de 1. Il n'y a pas de protocole pour indiquer le nombre de primitives. Les viewers doivent compter les paquets LLUDP et adapter le compte avec les changements. C'est la même chose pour les numéros de lien. Le viewer attribuera un numéro basé sur l'ordre dans lequel il a reçu le paquet LLUDP. Cela n'a aucun rapport avec l'ordre d'envoi. | |||
== Nombres de liens dans un objet lié == | |||
* Le nombre de liens d'un objet indiqué par le viewer est faux. Il faut trouver ce nombre avec un script. | |||
* Il semble que cela a été corrigé dans une récente mise à jour de Firestorm. | |||
= Tests = | = Tests = | ||
== Convertisseur SSL == | |||
=== Test d'hypergrid === | |||
* [[Réunion_du_24-09-2024#Test_du_convertisseur_de_Certificat | '''Test du convertisseur de certificat, réunion du 24-09-2024''']] | |||
* Web Rain dit que pour le moment il a eu aucun échec d'hypergrid depuis une standalone qui utilise le protocole HTTPS. Une grille fermée fonctionne bien également. Web Rain pense qu'une grille HG ne poserait pas de problème. | |||
=== Performances et SSL === | |||
* '''Plus de données''' pourrait rendre une plateforme moins accessible ou moins performante et [https://fr.wikipedia.org/wiki/Transport_Layer_Security '''SSL'''] deviendrait contre-productif. Le débit de données est le facteur limitant pour de nombreux propriétaires de grilles. | |||
* Ubit Umarov n'est pas sûr que [https://fr.wikipedia.org/wiki/Transport_Layer_Security '''SSL'''] représente plus de données en dehors de la [https://www.digicert.com/fr/faq/public-trust-and-certificates/what-is-a-tls-ssl-handshake '''négociation'''], dans de nombreux cas les données sont identiques. Mais, le '''CPU''' est plus utilisé. Une bonne '''négociation''' ajoute plus de données et quelques allers-retours supplémentaires, des '''connexions vers d'autres sites''' pour valider la chaîne du certificat. | |||
* '''WebRTC''' requiert SSL (voir [[#Chat_vocal_:_WebRTC_et_SSL| '''Chat vocal''']]). | |||
* Seules certaines personnes peuvent utiliser [https://letsencrypt.org/ '''let's encrypt''' ] (gratuit), il faut être propriétaire du domaine. Sinon, il faut payer un certificat [https://fr.wikipedia.org/wiki/Transport_Layer_Security '''SSL'''] à l'année ou utiliser un [https://fr.wikipedia.org/wiki/Certificat_autosign%C3%A9 '''certificat auto-signé''']. | |||
= Informations= | = Informations= | ||
== La Communauté OpenSimulator honore la mémoire d'Olivetree Lighthouse == | == La Communauté OpenSimulator honore la mémoire d'Olivetree Lighthouse == | ||
Ligne 14 : | Ligne 92 : | ||
Je voudrais dire quelques mots au sujet d'une amie chère que nous avons perdue récemment. Le Comité d'Organisation de la Conférence de la Communauté OpenSimulator honore la mémoire d'Olivetree Lighthouse, qui est décédée des suites d'une tumeur cérébrale. Elle aimait OpenSimulator et a travaillé comme bénévole et modératrice pour les présentations de l'OSCC et sur les stands des conférenciers de l'OSCC Expo Région 3. | Je voudrais dire quelques mots au sujet d'une amie chère que nous avons perdue récemment. Le Comité d'Organisation de la Conférence de la Communauté OpenSimulator honore la mémoire d'Olivetree Lighthouse, qui est décédée des suites d'une tumeur cérébrale. Elle aimait OpenSimulator et a travaillé comme bénévole et modératrice pour les présentations de l'OSCC et sur les stands des conférenciers de l'OSCC Expo Région 3. | ||
Olivetree, également | Olivetree, également connue sous le nom de PinkSamurai, nous manquera. Nous étions proches... nous avons travaillé ensemble pendant une douzaine d'années dans des mondes virtuels... et nous avons joué à World of Warcraft ensemble avec nos équipes de conférence à l'ISTE. Ses meshes sont omniprésents. | ||
Son profil : « Je suis venue aux mondes virtuels (SL puis Opensim) pour me connecter, enseigner, apprendre, explorer et prendre plaisir à connaître les gens et leur créativité. Je suis toujours | Son profil : « Je suis venue aux mondes virtuels (SL puis Opensim) pour me connecter, enseigner, apprendre, explorer et prendre plaisir à connaître les gens et leur créativité. Je suis toujours amoureuse de tout cela et du fait que je peux faire tout cela avec des gens du monde entier.» | ||
Je vous remercie. | Je vous remercie. | ||
Ligne 22 : | Ligne 100 : | ||
= Viewers= | = Viewers= | ||
== Absence de mise à jour d'informations après un TP== | == Absence de mise à jour d'informations après un TP== | ||
=== Problème === | |||
* orbert tatham a rencontré un bug avec Firestorm 7.x où la mer et le ciel sont perturbés à la suite d'une téléportation, même à l'intérieur d'OSGrid. | |||
=== Réponse === | |||
* L''''ancien problème des viewers''' demandant des données à la mauvaise région sur les tps n'a jamais été corrigé. Cela peut aussi avoir un impact sur l'environnement, le nom des avatars et des NPC. Ce n'est pas lié à la version 7.x de Firstorm. | |||
* Le viewer obtient les informations de la nouvelle région, mais il continue de les demander à l'ancienne région. Cela tue les noms des npc, les noms des avatars HG, les textures locales, les textures HG… etc. | |||
* '''Ce bug ne sera jamais corrigé''' parce qu'il est lié à la structure globale de Second Life et aussi parce que c'est un problème de timing très difficile à déboguer. | |||
* C'est aussi un bug qui '''touche les régions proches'''. Les viewer peut demander à la région principale ce qui se passe sur des régions enfant, les noms de npc, les textures locales, etc. seront ignorés. | |||
== Peut-on désactiver PBR dans Firestorm 7.X ? == | |||
* [[Lexique_des_réunions#PBR |'''PBR''']] fait partie intégrante de la version 7.X de [[Lexique_des_réunions#Viewer_Firestorm | '''Firestorm''']], '''on ne peut pas le désactiver'''. Le moteur de rendu a été changé pour [[Lexique_des_réunions#PBR |'''PBR''']]. | |||
* On peut supprimer le traitement de certains [[Lexique_des_réunions#PBR |'''PBR''']] dans Firestorm 7.X. Cela aide un peu mais, Firestrom 7.x est toujours plus lent que Firestorm 6.X. | |||
= Source= | = Source= | ||
http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2024-10-01 | http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2024-10-01 |
Dernière version du 4 octobre 2024 à 12:09
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.😉 |
Noyau
Données liées à des grilles disparues
Problème posé par Vincent Sylvester
- L'interconnexion entre les grilles permet de récupérer toutes sortes de données (surtout le nom des créateurs mais aussi des amis ou des groupes). Lorsqu'une grille disparaît, ces données pointent dans le vide ce qui peut provoquer une augmentation des délais de recherche des DNS.
- La situation n'est pas aussi grave que ce que pouvait imaginer Vincent Sylvester, probablement en partie parce qu'il n'y a pas beaucoup de contenu en circulation. Dans le pire des cas, il y avait 15 000 échecs de DNS dans 50 régions à partir de plusieurs mois de données de log.
- Pour tester les données cassées d'une région, on peut rechercher NameResolutionFailure dans le journal de la région (bin/OpenSim.log).
- Le problème peut se révéler par exemple si de très nombreux assets de régions défuntes sont stockés sur une région. Certains propriétaires de grille "s'approprient" certains assets pour éliminer le délai DNS... ou pour "éliminer" d'autres choses...
NDLR : J'ai fait une recherche dans le log de la région Argentoratum sur la grille du même nom et j'obtiens les lignes suivantes : 2024-05-09 21:47:18,619 DEBUG [USER AGENT CONNECTOR]: get_server_urls call to http://<Nom de domaine>:8002/ failed: Error: NameResolutionFailure 2024-05-09 21:47:18,620 DEBUG [USER MANAGEMENT MODULE]: GetServerURLs call failed Error: NameResolutionFailure |
Solutions possibles
- Remplacer le nom de domaine lié à la donnée et la relier localement, mais cela a ses propres implications (NDLR : propriétaire, amis ou groupes inexistants, etc).
- Utiliser une liste noire en interne si ces données erronées encombrent significativement une région, Mais il est difficile de garder une liste noire automatique d'échecs de DNS parce que les DNS échouent de temps en temps sur des choses valides. Il faudrait maintenir cette liste manuellement sur la base de la liste des grilles fermées connues. Mais, cela n'évitera pas le problème des standalones ou autres urls à courte durée de vie.
- La configuration d'une liste noire pour chaque région serait très laborieux. Un service comme mutelist[1][2] serait peut-être plus efficace. Il serait possible d'utiliser une partie de ce code, ce serait une liste manuelle que Robust distribuerait aux régions. Robust pourrait même vérifier régulièrement si les liens sont vraiment morts et les régions demanderaient ces données une fois par jour. Ubit Umarov dit qu'à un moment donné, cette liste pourrait être aussi longue que le celle des assets.
- Quand la recherche DNS échoue, aucune donnée factice de remplacement n'est envoyée. Cela pourrait être ajusté immédiatement en renvoyant un profil vide au viewer pour qu'il ne reste pas bloqué. ( D'ailleurs un certain nombre de processus pourraient voir leurs délais améliorés avec des valeurs par défaut de ce type).
- Il faut également vérifier où des données potentiellement erronées sont mises en cache.
Problèmes hypergrid , est-ce la faute de dotnet ?
Question
- Est-ce que le remplacement de Mono par dotnet est coupable de tous les problèmes que les gens rencontrent en hypergrid ?
Réponse
- Les utilisateurs ont toujours eu des problèmes avec l'hypergrid. Il est plus probable que la cause réside dans des versions différentes du système d'exploitation entre la source et la destination, plutôt que dans des problèmes liés à dotnet et mono.
- Cuga Rajal n'a pas de problème d'Hypergrid avec la version 0.9.3 d'OpenSim. En revanche, dans Osgrid, ce sont les régions qui fonctionnent avec d'anciennes versions qui lui poseraient des problèmes.
Modules
Chat vocal : WebRTC et SSL
- WebRTC Requiert SSL.
- WebRTC interdit les certificats auto-signés.
Carte
Problème
- Web Rain a rencontré ce message dans la console :
[WARNING]: EOC marker not found. Codestream is corrupted.
Réponse
- Ce message vient du moteur de rendu maptile, on peut l'ignorer.
Bugs
Déclenchement d'object_rez
- Mantis 0009165 : object_rez n'est pas déclenché avant la fin de state_entry()
- Ce n'est pas un bug, c'est un comportement attendu.
- Erreur dans le titre du rapport de bug il faut lire object_rez à la place de on_rez.
NDLR : Fonctions et événements LSL utilisés
Représentation schématique du problème (c'est comme cela que je me le représente... ) |
- Explication d'Ubit Umarov dans les commentaires de la Mantis
- Les événements d'un script sont exécutés un à la fois , par ordre d'arrivée dans la file d'attente (Ndlr : ici state_entry puis object_rez). Donc, object_rez(key id) ne sera exécuté qu'après avoir quitté state_entry() et après tout autre événement ayant atteint la file d'attente avant lui.
- llRezAtRoot fonctionne de manière asynchrone, c'est-à-dire qu'il y a un thread pour A et un autre pour B, et donc B peut se terminer avant A. Il n'y a pas de relation temporelle entre le rez et l'événement object_rez(key id).
- Dans les commentaires de la Mantis, JeffKelley propose un script pour contourner le problème.
LI dans opensim est juste indicatif
NDLR : Il faudrait faire des tests dans le viewer, je ne sais pas à quoi correspond LI. ... J'y reviendrai peut-être. |
- Cuga Rajal a un mesh 1-LI qu'il relie à un cylindre plat régulier 1-LI.
- Quand les deux objets (mesh + cylindre) sont liés, le viewer indique que l'objet lié contient 30-LI (30 liens/objets ?) . Quand le mesh et le cylindre sont déliés, l'ensemble revient à 2-LI. Cela, même si le mesh est sur Physics Type None.
- Dans Blender le mesh était composé de 30 objets que Cuga Rajal a joints pour n'en faire plus qu'un. Il a optimisé le mesh puis l'a exporté et importé avec une forme physique de cube.
- Ubit Umarov dit que LI dans OpenSim est indicatif. Les primitives sans mesh ont un LI de 1. Il n'y a pas de protocole pour indiquer le nombre de primitives. Les viewers doivent compter les paquets LLUDP et adapter le compte avec les changements. C'est la même chose pour les numéros de lien. Le viewer attribuera un numéro basé sur l'ordre dans lequel il a reçu le paquet LLUDP. Cela n'a aucun rapport avec l'ordre d'envoi.
Nombres de liens dans un objet lié
- Le nombre de liens d'un objet indiqué par le viewer est faux. Il faut trouver ce nombre avec un script.
- Il semble que cela a été corrigé dans une récente mise à jour de Firestorm.
Tests
Convertisseur SSL
Test d'hypergrid
- Test du convertisseur de certificat, réunion du 24-09-2024
- Web Rain dit que pour le moment il a eu aucun échec d'hypergrid depuis une standalone qui utilise le protocole HTTPS. Une grille fermée fonctionne bien également. Web Rain pense qu'une grille HG ne poserait pas de problème.
Performances et SSL
- Plus de données pourrait rendre une plateforme moins accessible ou moins performante et SSL deviendrait contre-productif. Le débit de données est le facteur limitant pour de nombreux propriétaires de grilles.
- Ubit Umarov n'est pas sûr que SSL représente plus de données en dehors de la négociation, dans de nombreux cas les données sont identiques. Mais, le CPU est plus utilisé. Une bonne négociation ajoute plus de données et quelques allers-retours supplémentaires, des connexions vers d'autres sites pour valider la chaîne du certificat.
- WebRTC requiert SSL (voir Chat vocal).
- Seules certaines personnes peuvent utiliser let's encrypt (gratuit), il faut être propriétaire du domaine. Sinon, il faut payer un certificat SSL à l'année ou utiliser un certificat auto-signé.
Informations
La Communauté OpenSimulator honore la mémoire d'Olivetree Lighthouse
Hommage de Lyr Lobo à Olivetree Lighthouse
Je voudrais dire quelques mots au sujet d'une amie chère que nous avons perdue récemment. Le Comité d'Organisation de la Conférence de la Communauté OpenSimulator honore la mémoire d'Olivetree Lighthouse, qui est décédée des suites d'une tumeur cérébrale. Elle aimait OpenSimulator et a travaillé comme bénévole et modératrice pour les présentations de l'OSCC et sur les stands des conférenciers de l'OSCC Expo Région 3.
Olivetree, également connue sous le nom de PinkSamurai, nous manquera. Nous étions proches... nous avons travaillé ensemble pendant une douzaine d'années dans des mondes virtuels... et nous avons joué à World of Warcraft ensemble avec nos équipes de conférence à l'ISTE. Ses meshes sont omniprésents.
Son profil : « Je suis venue aux mondes virtuels (SL puis Opensim) pour me connecter, enseigner, apprendre, explorer et prendre plaisir à connaître les gens et leur créativité. Je suis toujours amoureuse de tout cela et du fait que je peux faire tout cela avec des gens du monde entier.»
Je vous remercie.
Viewers
Absence de mise à jour d'informations après un TP
Problème
- orbert tatham a rencontré un bug avec Firestorm 7.x où la mer et le ciel sont perturbés à la suite d'une téléportation, même à l'intérieur d'OSGrid.
Réponse
- L'ancien problème des viewers demandant des données à la mauvaise région sur les tps n'a jamais été corrigé. Cela peut aussi avoir un impact sur l'environnement, le nom des avatars et des NPC. Ce n'est pas lié à la version 7.x de Firstorm.
- Le viewer obtient les informations de la nouvelle région, mais il continue de les demander à l'ancienne région. Cela tue les noms des npc, les noms des avatars HG, les textures locales, les textures HG… etc.
- Ce bug ne sera jamais corrigé parce qu'il est lié à la structure globale de Second Life et aussi parce que c'est un problème de timing très difficile à déboguer.
- C'est aussi un bug qui touche les régions proches. Les viewer peut demander à la région principale ce qui se passe sur des régions enfant, les noms de npc, les textures locales, etc. seront ignorés.
Peut-on désactiver PBR dans Firestorm 7.X ?
- PBR fait partie intégrante de la version 7.X de Firestorm, on ne peut pas le désactiver. Le moteur de rendu a été changé pour PBR.
- On peut supprimer le traitement de certains PBR dans Firestorm 7.X. Cela aide un peu mais, Firestrom 7.x est toujours plus lent que Firestorm 6.X.
Source
http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2024-10-01