Réunion du 10-06-2025

Changements du code de la semaine

Problème d'alpha -- mantis 9205

Mantis 9205

• Mantis 9205 : les fonctions llSetPrimitiveParams et llGetPrimitiveParams inversent l'alpha pour le drapeau (flag)[1] PRIM_TEXT (et éventuellement d'autres drapeaux).
• llSeltPrimitiveParms :

 llSetLinkPrimitiveParams( integer link, list rules );

Permet de modifier la primitive en appliquant les règles définies dans les paramètres.

• llGetPrimitiveParams :

 list llGetPrimitiveParams( list paramètre ); 

Renvoie un list correspondant à la liste des propriétés de la primitive demandées dans le paramètre.

Commit 74c64e

• Commit 74c64e : mantis 9205 : correction de l'alpha du texte pour LSL.
• Il y avait un problème d'affichage de la transparence(alpha) du texte placé au dessus d'une primitive.
• Une fonction du code d'OpenSimulator a été créée pour convertir les couleurs de System.Drawing.Color en Color4, cette fonction est spécifiquement conçue pour LLUDP. Il se trouve que plus tard cette fonction a aussi été utilisée pour obtenir l'alpha pour les scripts LSL. Il y a eu une inversion de la valeur alpha : la valeur 0 (transparent), était traitée comme la valeur 1 (opaque). (Ndrl : je n'ai pas compris pourquoi cette inversion et le rôle de l'encodeur zero qui semble être à l'origine de l'inversion.)
• System.Drawing.Color est une structure utilisée dans le .NET Framework pour représenter les couleurs, y compris leur composante alpha pour la transparence.
• Format Color4 : format de couleur qui inclut quatre composantes : rouge, vert, bleu et alpha
• Remarque d'après Ubit Umarov : il semble que le code ne se contentait pas de gérer les couleurs, mais effectuait également des conversions entre différents formats de couleur, par exemple, de bytes à floats et vice versa, ce qui compliquait le code. La gestion des couleurs est devenue trop complexe, notamment parce que les valeurs ne sont pas stockées directement et nécessitent des appels supplémentaires pour obtenir la valeur réelle. De plus, la gestion des textures dynamiques est lourde en raison de ces complications inutiles.

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

Informations

Informations sur les Utilisateurs de macOS Utilisant OpenSim

Question

• Joe Magarac demand s'il existe une utilisation significative de MacOS dans la communauté d'OpenSimulator ?

Réponse

• Gavin Hird répond qu'il est difficile de les quantifier exactement, car il n'y a pas de statistiques centralisées.
• Vincent Sylvester pense que le nombre d'utilisateurs de MacOS côté client OpenSim est plus élevé que la proportions générale des utilisateurs de MacOS. En revanche côté serveur, c'est vraiment Linux qui est le plus adapté pour la plupart des applications, à moins d'être submergé de machines macOs.

Viewers

Sharpview

Questions de Joe Magarac

Question 1

• Si vous pouvez conduire entre d'une régions OpenSim à une autre, est-ce que les régions doivent avoir le même serveur d'assets ?

Réponse 1

• Non, tant que les viewers le gèrent correctement. Les viewers doivent utiliser le serveur d'assets de chaque région. Ils doivent exploiter ce que les capacités des régions leur indiquent d'après les anciennes spécifications de Linden Lab.

Question 2

• Que se passe-t-il lorsqu'un véhicule est conduit d'une région à l'autre et qu'un viewer de la nouvelle région le voit ? Où obtient-il l'inventaire ? Que se passe-t-il si vous roulez suffisamment loin pour que la région qui le voit n'ait aucune connexion avec la région qui l'a rezzé ?

Réponse 2

• Le viewer a des connexions indépendantes avec chaque région (les clients enfants) et chaque connexion a un ensemble complet de capacités, URLs, ect. Lorqu'on se déplace dans la région les connexions sont mises à jour.
• Ainsi, quand on arrive à un certain point, il indique au viewer les régions auxquelles se connecter et celles qu'il doit abandonner.

Question 3

• Mais que se passe-t-il lorsque vous rezzez quelque chose dans la région A, et que vous le conduisez dans les régions B, C, D, E, et que E est hors de portée ? Comment E trouve-t-il l'asset ? L'asset n'est pas connu de E.

Réponse 3

• Il doit être présent dans un service d'assets backend (secondaire). Par exemple l'objet voiture lui-même est envoyé sur le téléport

Question 4

• Vous envoyez réellement les fichiers d'assets entre les serveurs ?

Réponse 4

• Les objets sont spéciaux, seuls les objets de l'inventaire reçoivent un asset de la grille OpenSim. Les autres sont des assets qui appartiennent seulement à la région.
• Lorsque qu'on se déplace d'une région à l'autre, il n'y a pas de problème car les données des assets sont dans le cache du viewer.

Question 5

• Mais lorsque qu'on arrive dans la région E, un autre utilisateur voit l'objet déplacé ? Où est-ce que le viewer obtient l'asset ? comment fonctionnent les actifs qui ne sont pas locaux aux régions ? Est-ce que les serveurs de simulation les copient entre eux ?

Reponse 5

• Le viewer devrait toujours utiliser les capacités des régions.
• Les régions ont toutes un serveur d'asset backend partagé, les régions fonctionnent comme des caches de celui-ci. Certaines grilles fonctionnent comme un réseau de diffusion de contenu (RDC).
• Il faut demander au viewer de se connecter directement au RDC comme à un service d'assets. Bien sûr, cela ne fonctionnera pas pour les assets locaux. Quoi qu'il en soit, les régions indiquent au viewer l'URL à utiliser pour avoir accès à l'asset.

Imposteurs

• 🏗️

Source

• http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2025-06-10