Réunion du 25-11-2025

Changements du code de la semaine

Chargeur TIFF

• Commit 2db1fa : Chargeur TIFF jusqu'à 32 bits flottants, cosmétiques.
• Vincent Sylvester a étendu le chargeur TIFF pour qu'il utilise des nombres à virgule flottante 32 bits et puisse également charger certains formats moins courants. Comme le format TIFF peut être utilisé dans la plupart des éditeurs de photos et qu'il prend en charge le format qu'OpenSim utilise pour les heightmaps, cela semble être une bonne option. Le format PNG et les autres arrondissent ou coupent les données, car leur format ne prend pas en charge les nombres à virgule flottante 32 bits.
• Vincent Sylvester a également ajouté un moyen de vérifier si le terrain a une hauteur qu'un chargeur spécifique tronquerait à 256 mètres.
• Il a décalé la conversion en niveaux de gris de 256 points vers le bas pour tenir compte du terrain négatif, pour permettre aux fichiers TIFF existants de se charger beaucoup plus bas.
• C'est un format qui correspond exactement aux cartes d'altitude en interne et qui peut être facilement modifié.
• À l'origine, cette modification faisait partie d'une refonte plus large de l'ensemble du système de tuiles de carte, des générateurs et du service de carte, mais Vincent Sylvester a isolé cette partie pour faciliter la compréhension.

Corection de PostgreSQL

• Commit 8714f5 : Quelques modifications apportées à pgsql, merci Tampa (non testées, il peut y avoir des erreurs).
• PostgreSQL fonctionne à nouveau, le code a été testé sur la version 18 et cela fonctionne.

Le problème

• La semaine dernière Vincent Sylvester avait signalé que PostgreSQL 18(dernière version) faisait planter OpenSim. Apparemment, une partie du code essayait de comparer une chaîne à un UUID ou plutôt à un GUID, ce qui a fait exploser les connexions.

Discussion

• Maintenant, les connexions fonctionnent avec PostegreSQL 18. Il y avait également un petit bug dans XAssets qui a été corrigé. Probablement parce que personne ne l'utilise, il n'a pas été détecté.
• À l'origine dans OpenSim, les UUID étaient stockés sous forme de CHAR36 comme sur MySQL. Mais ensuite, il y a eu un changement pour utiliser l'UUID natif et tous les codes n'ont pas reçu les modifications nécessaires.
• À la version 15, PostegreSQl a imposé la comparaison des types pour qu'ils soient identiques, donc la comparaison d'une chaîne avec un UUID explose. Vincent Sylvester avait rencontré ce problème en testant des versions récentes de PostgreSQL. Au départ il pensait qe le souci venait du connecteur et non du wrapper.
• Dans PostegreSQL il existe apparemment des moyens d'accélérer considérablement certaines requêtes, mais cela relève du réglage de la base de données, un domaine que Vincent Sylvester dit ne pas très bien maîtriser.

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

Base de données

Migration

• Vincent Sylvester a encore la réécriture de la migration des bases de données en attente, qui doit finalement être intégrée, mais cela nécessite encore quelques ajustements et tests.

Vues matérialisées et jointures

NDLR  : En informatique, dans les systèmes de gestion de base de données de type relationnel, une vue est une table virtuelle représentant le résultat d’une requête sur la base [1]. Le principe est de regrouper les données de plusieurs tables dans une vue matérialisée, puis d'exécuter la recherche sur la vue et non sur plusieurs tables. En informatique et plus particulièrement dans les bases de données relationnelles, la jointure ou appariement est l'opération permettant d’associer plusieurs tables ou vues de la base par le biais d’un lien logique de données entre les différentes tables ou vues, le lien étant vérifié par le biais d'un prédicat. [2]

Discussion

• Gavin Hird recommande d'adopter les vues matérialisées, susceptibles d'être utilisées à de nombreux endroits dans les requêtes de base de données d'OpenSim, par exemple pour l'inventaire, les groupes et la recherche, plutôt que de manipuler les tables de manière aussi complexe que c'est le cas actuellement. Il ne sait pas si la version libre de MySQL dispose des vues matérialisées..
• Vincent Sylvester a essayé quelques options dans MariaDB, mais il n'a pas pu déterminer si les requêtes étaient plus rapides ou non. Il a aussi alloué beaucoup de mémoire pour la mise en cache des tables, ce qui semble être le plus efficace.
• Les tables d'OpenSim n'ont pas le même jeu de caractères, cela rend ces appelles extrêmement lents. Toutes les opérations de jointure qui nécessitent une conversion de données prend une éternité. Si les tables étaient unifiée aux mêmes jeux de caractères, les jointures internes prendraient moins d'une seconde. Vincent Sylvester s'occuper de ce problème (voir ci-dessous). Mais, il confirme que les vues matérialisées seraient encore plus rapide.

Test

• Vincent a fait un test de recherche Web sur ZetaWorlds qui compte 2500 utilisateurs, des dizaines d'articles de blog, des lieux, des petites annonces, etc. La recherche a trouvé 33 résultats en : 0,04070019721984863 secondes.

Mise à l'échelle

• Gavin Hird évoque également la Mise à l'échelle / extensibilité d'un simulateur. (NDRL : Un simulateur qui fonctionne pour un petit nombre d'utilisateurs peut rencontrer des problèmes s'il voit sa fréquentation augmenter. ) La base de données est saturée par le nombre de requêtes envoyées simultanément.
• Vincent Sylvester répond qu'il suffit d'ajouter des ressources matérielles pour résoudre le problème.
• Gavin Hird pense que les écritures dans la base de données sont généralement assez lentes, quel que soit le matériel.

Encodages des caractères

NDLR  : OpenSim prend en charge les emojis, beaucoup d'icônes Unicode sont désormais disponibles. Caractères latins : Ce terme fait référence aux lettres et symboles provenant de l'alphabet latin, principalement utilisé pour écrire les langues d’Europe de l'Ouest, d'Europe du Nord et d'Europe centrale, ainsi que les langues de nombreux pays qui ont été exposés à une forte influence européenne.[3] Unicode définit un ensemble universel de caractères, chacun ayant un identifiant unique. Il permet des échanges de textes dans différentes langues, à un niveau mondial. Unicode ne spécifie pas comment les caractères doivent être encodés. [4]. UTF-8 est un codage de caractères informatiques qui permet de représenter tous les caractères Unicode. utf8mb3 est une variante du codage UTF-8, souvent utilisée dans les systèmes de gestion de bases de données comme MySQL. C'est un format de codage qui représente des caractères en utilisant jusqu'à trois octets. utf8mb4 est une extension de utf8mb3, également utilisée dans des systèmes de bases de données comme MySQL. C'est un format qui encode jusqu'à quatre octets par caractère. Cela permet de représenter une gamme beaucoup plus large de caractères, y compris tout ce que utf8mb3 ne peut pas gérer. ASCII est une norme informatique d'encodage de caractères. Elle contient 128 points de code codés sur 7 bits et permet d'encoder les chiffres arabes de 0 à 9, les 26 lettres de l'alphabet latin en minuscules et en capitales, des symboles mathématiques et de ponctuation. Un Emoji est un pictogramme utilisé dans un message électronique ou sur une page web. Bien qu'originaires du Japon, certains jeux de caractères émojis sont intégrés à Unicode, permettant leur utilisation partout dans le monde. 😊

• Les réponses aux requêtes de base de données sont extrêmement lentes en raison des incompatibilités entre les jeux de caractères des tables, ce qui rend les opérations de jointure très lentes en nécessitant des conversions de données.
• Vincent Sylvester a tout unifié en utf8mb4 general_ci champs et tables, sans plus. D'après ce qu'il sait, cet encodage peut gérer tout ce qui est latin1 et, même s'il est assez lourd en termes de données, il devrait permettre de traiter tous les éléments étranges que la base de données rencontre. Il peut y avoir des problèmes de compatibilité avec les caractères latins lorsqu’on utilise le codage utf8mb3, tandis que le codage utf8mb4 gère ces caractères sans difficulté.
• Jusqu'à présent il n'a rien vu qui ne fonctionne pas. Cela utilise certes plus de données, mais comme c'est uniforme, beaucoup de requêtes sont plus rapides et il y a beaucoup d'informations utiles à gagner avec les jointures.
• Ubit Umarov pense qu'il n'y a aucun intérêt à utiliser UTF-8 pour certaines choses comme les UUID et d'autres éléments qui n'utilisent que l'ASCII, tout déplacer vers utf8mb4 est une erreur.
• Vincent Sylvester trouve que l'uniformité facilite l'utilisation pour les requêtes spéciales et, en réalité, cela ne gaspille pas beaucoup d'espace supplémentaire. C'est un compromis qu'il est prêt à faire.
• Ubit Umarov précise que c'est tout de même 4 fois plus d'espace et que les comparaisons sont plus lentes. Les principaux problèmes de performance de mb4 concernent les index qui sont essentiellement de type int32.
• Gavin Hird dit que dans PostegreSQL les enregistrements font de toute façon 8 ko (sauf pour les BLOB) , donc il y a généralement beaucoup d'espace disponible.
• Vincent Sylvester insiste sur le fait que beaucoup de lenteurs ne sont pas dues à l'utilisation d'utf8mb4 et qu'il serait avantageux d'utiliser les jointures au niveau de la base de données plutôt que dans le code. Finalement, pour la plupart des choses, il faut que ce soit compatibles pour ne pas se soucier d'un petit changement dans l'Unicode qui ferait immédiatement exploser votre base de données.
• Ubit Umarov pense que utf8mb3 couvre la plupart des utilisations alors que Vincent Sylvester précise que des cas particuliers continuent d'apparaître et que utf8mb4 est nécessaire.

Informations

OSCC 2025

• Nous sommes à environ une semaine et demie du week-end OSCC.
• Vendredi 5 décembre il y a trois concerts à partir de midi, heure du Pacifique et 21h heure de Paris.
• La conférence débute samedi à 7 h avec le plateau des Développeurs (samedi 16h heure de Paris) .
• Le plateau des VIP est à 11 h 45 PST , 20h45 heure de Paris.
• Le programme officiel est en ligne à l'adresse https://conference.opensimulator.org/compact-schedule/ . Ajoutez 9h aux horaires si vous utilisez l'heure de Paris.
• La conférence sera diffusée en direct sur la chaîne Youtube AvaconInc.
• La conférence utilise Discord pour la voix et elle sera diffusée dans le flux musical des viewers.

Viewers

Chat vocal

• Vivox ne semble pas avoir désactiver la voix sur OpenSim. Elle fonctionne toujours.
• Il y avait quelques problèmes de voix sur des systèmes basés sur UNIX. Si c'est le cas, il faut mettre le viewer à jour.
• La région Welcome sur Zetaworlds dispose de quelques parcelles avec la voix où il est possible de tester le chat vocal.

Firestorm

Idée de traducteur OpenSim intégré

• Vincent Sylvester c'est entretenu avec des responsables de Firestorm au sujet de l'onglet « Centres d'intérêt » qui a disparu depuis longtemps dans le profil. Il pense qu'il pourrait être recyclé pour utilisé les données qu'il contient afin de créer un traducteur directement dans OpenSim.
• Cela semble peu probable car le travail nécessaire pour le rétablir est trop important. Cependant, cela laisse la question de l'utilisation des données contenues dans la base de données en suspens.

Source

http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2025-11-25