← Modification précédente Modification suivante →

Version du 21 septembre 2025 à 13:34

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

Bibliothèques

Moteurs Physiques et gestion des maillages

Définitions

Un moteur physique est, en informatique, une bibliothèque logicielle conçue pour simuler des systèmes physiques, comme en mécanique des solides (déformables ou non-déformable) ou en mécanique des fluides. Ils sont utilisés dans des domaines tels que la conception assistée par ordinateur, les jeux vidéos ou les films.
La tesselation (pavage) est un processus qui consiste à subdiviser des surfaces en polygones plus petits, généralement des triangles. Cela permet d'améliorer le niveau de détail d'un modèle 3D.
Un objet convexe est un objet où, pour chaque paire de points à l'intérieur de la forme, la ligne droite qui les relie est également à l'intérieur de la forme.
La décomposition convexe est le processus de division d'un objet 3D en plusieurs objets convexes. La décomposition convexe simplifie les calculs de collision. Cependant, la décomposition convexe peut parfois être complexe et entrainer des problèmes si les formes ne sont pas bien définies. Exemple de décomposition convexe : un objet en forme de L peut être diviser en deux formes convexes, un rectangle et un carré.

Différents moteurs physique

ubODE : moteur physique développé par Ubit Umarov pour OpenSimulator, basé sur le moteur physique ODE (Open Dynamics Engine).
BulletSim : BulletSim est un module pour OpenSimulator qui crée la physique du monde virtuel en utilisant le Moteur physique Bullet.
Havok est le moteur physique propriétaire utilisé par Second Life.
PhysX est un moteur physique en temps réel, propriété de Nvidia sous licence BSD-3.
BEPUphysics est une bibliothèque de physique 3D gratuite, open source, écrite entièrement en C. BEPUphysics a une liaison pour C#.
JoltPhysics : est un moteur de physique de jeu multi-cœur. JoltPhysics a une liaison pour C#.
CryEngine : est un moteur de jeu développé par Crytek sous licence propriétaire, spécialisé dans les jeux de tir à la première personne.

Discussion

Joe Magarac dit qu'il existe maintenant une décomposition convexe approximative. Un certain chevauchement est autorisé, ce qui induit moins de cas problèmes.
Ubit Umarov dit que la décomposition convexe n'est pas recommandée pour la physique dans OpenSim. Le moteur physique UbODE n'utilise pas de décomposition convexe. Bullet fait sa propre décomposition. Il souligne que la physique n'est pas lié à la vue.
Bullet semble ne plus être maintenu bien que Cuga Rajal précise que Bullet reçoit encore des mises à jour et qu'il est passé à une nouvelle version il y a un an. Mais, même si Bullet n'était plus maintenu, ce n'est pas grave, car d'après Ubit Umarov, la physique simple n'a pas changé .
Il semble que Second Life s'éloigne de Havok pour explorer d'autres options.
C# a des liaisons pour d'autres moteurs physiques, comme par exemple PhysX (propriété de Nvidia), BEPUphysics et JoltPhysics , il suffit d'ajouter des modules dans OpenSim pour pouvoir les utiliser. Mais, c'est plus facile à dire qu'à faire.
D'après Ubit Umarov, le niveau d'ouverture actuel et futur du code de PhysX est incertain. Il ajoute que beaucoup de jeux finissent par utiliser leurs propres moteurs physique. Unreal qui utilisait PhysX utillise maintenant son propre moteur physique Chaos. Unity utilise PhysX.

Viewers

Sharpview

Imposteurs de région pour OpenSim

Introduction

Les imposteurs -- réunion du 03 juin 2025
Les imposteurs -- réunion du 10 juin 2025
Joe Magarac annonce qu'il a trouvé une méthode pour créer des imposteurs de région pour OpenSimulator.
Il a deux types d'imposteurs :

Cas où toutes les régions d'un groupe ont la même taille : dans ce cas elles peuvent utiliser des imposteurs 4x, 16x, 64x pour gérer les niveaux de détails (LOD).
Cas où les régions d'un groupe ne sont pas toutes de la même taille : dans ce cas elles utilisent des imposteurs 1x seulement.

Un imposteur 64x représente 8 régions x 8 régions, c'est une vue très éloignée de toutes ces régions à la fois.
Les imposteurs ont des maillages réduits.
Actuellement, les imposteurs en test sont juste une heightmap avec une texture. IL n'y a pas encore de bâtiments. Mais on peut voir des montagnes au loin. Il travaille sur la création de meilleurs imposteurs pour les zones urbaines en utilisant OpenDroneMap.
C'est surtout pour Second Life, mais, Joe Magarac aimerait aussi développer cette fonctionnalité pour OpenSimulator.
Il pense faire faire des mises à jour hebdomadaires par un bot.
Les régions uniques sans voisins n'ont pas besoin d'imposteurs.

Taille des régions et continents de régions sur OpenSim

Joe Magarac estime que le plus grand cluster de régions contigües dans OpenSimulator semble être d'environ 100 régions sur OSGrid.
Vincent Sylvester dit qu'il a 500 régions de 1024x1024 connectées comme un grand océan sur ZetaWorld. C'est l'équivalent de 13000 régions normales.
- Exemple 1 : https://zetaworlds.com/map?x=7380&y=6971&z=2
- Exemple 2 : https://zetaworlds.com/map?x=6988&y=6954&z=2
Ubit Umarov souligne que cela dépend des grilles et que certaines ont des zones "continentales". Il signale aussi que les continents produisent davantage de lag, donc les gens préfèrent juste l'isolement.

Régions voisines de tailles différentes

Les viewers codés en C++ ne supportent qu'une seule région voisine par côté. Si on place deux régions sur un des côtés d'une plus grande région, lors d'une téléportation, le viewer crash la moitié du temps.
Sharpview supporte les régions supportent plusieurs régions voisines par côté.

Placement possible des régions

Imposteurs et spam d'assets

Vincent Sylvester s'inquiète de l'impact potentiel sur les ressources et espère que cela ne produira pas trop de spams d'assets.
Il pense que Joe Magarac sous-estime le spam d'assets qui existe et qu'y ajouter encore d'autres assets n'est pas judicieux.
Joe Magarac signale que ce serait un seul asset par région.
Mais, Vincent sylvester répond qu'OpenSimulator stocke déjà les images des cartes. C'est un nouvel asset à chaque mise à jour qui ne sera pas nettoyé automatiquement.
Il prend un exemple pour expliquer son point de vue : il estime que les imposteurs font 1 Mo par région pour 1000 régions ce qui fait déjà 1 Go d'assets. Il pense que les mises à jour pourraient demander 350Mo en plus par an. Le stockage des serveurs est limité et payant.

Stockage côté serveur ou côté viewer

Vincent Sylvester ne comprend pas pourquoi les imposteurs ne seraient pas stockés localement côté viewer au lieu de surcharger le serveur du simulateur. Le viewer a la capacité de générer des maillages et des textures à un rythme bien meilleur que le CPU du serveur, étant donné que les viewers utilisent un GPU.
Joe Magarac répond que le viewer doit obtenir les imposteurs de quelque part.
Vincent Sylvester propose de faire quelques modifications sur les gestionnaires HTTP côté grille afin de permettre à Sharpview d'interroger les voisins d'une région pour obtenir en retour leurs adresses HTTP. Il ajouterait également un gestionnaire HTTP qui renverrait la hieghtmap et l'image de la carte. Ainsi le viewer pourrait localement générer un maillage texturé et le stocker dans le dossier du cache local. Cela ne donnera pas les bâtiments mais c'est un début.
La création d'imposteurs depuis le viewer permettrait à un utilisateur de désactiver ou d'activer cette fonctionnalité selon ses besoins, même si la région n'a pas de voisins. Cela donne un contrôle de la vie privée au propriétaire de la région.
Il va mettre des régions tests à la disposition de Joe Magarac sur sa grille Zetaworlds.

Distance d'affichage dans OpenSIm

Ubit Umarov signale que la distance d'affichage des régions est un paramètre qu'il faut prendre en compte dans OpenSim. Il dit que la forme du terrain des régions voisines change beaucoup à mesure qu'on s'en approche.
Les régions peuvent être configurées pour dire aux viewers de se connecter très loin.

NDLR :

Dans le viewer on peut augmenter la distance de visibilité depuis le menu Paramètres/ Graphique/ Distance d'afficahge.
Dans le fichier OpenSim.ini, utilisé pour configurer un simulateur, certains paramètres influencent la distance d'affichage (ici les commentaires sont traduits en français). Je ne crois pas q'Ubit Umarov voulait parler de ces paramètres, maintenant c'est là, peut-être qu'il sont aussi importants pour afficher des imposteurs ? :

 [InterestManagement]
     ;; Cette section contrôle la manière dont la priorité est attribuée aux mises à jour dans le viewer (client).
     ;# {UpdatePrioritizationScheme} {} {Schéma de priorisation des mises à jour ?} {BestAvatarResponsiveness SimpleAngularDistance} BestAvatarResponsiveness
     ;; Les valeurs valides sont  BestAvatarResponsiveness et SimpleAngularDistance
     ;; SimpleAngularDistance utilise davantage de ressources CPU.
     ; UpdatePrioritizationScheme = BestAvatarResponsiveness

     ;; ObjectsCullingByDistance,  si true, n'envoie pas les mises à jour des objets s'ils sont hors de la zone de vision
     ;; actuellement, les viewers sont également invités à supprimer les objets qui quittent la zone de vision
     ;; seule la position de l'avatar est prise en compte, la caméra libre peut ne pas voir les objets
     ;;  augmente la charge CPU
     ; ObjectsCullingByDistance = false

Source

http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2025-06-17

@@ Ligne 9 : / Ligne 9 : @@
 * '''La décomposition convexe'''  est le processus de division d'un objet 3D en plusieurs objets convexes. La décomposition convexe  simplifie les calculs de collision. Cependant, la décomposition convexe peut parfois être complexe et entrainer des problèmes si les formes ne sont pas bien définies. Exemple de décomposition convexe : un objet en forme de L peut être  diviser en deux formes convexes, un rectangle et un carré.
-=== Différentes moteurs  physique ===
+=== Différents moteurs  physique ===
 * '''[https://github.com/opensim/opensim/tree/master/OpenSim/Region/PhysicsModules/ubOde ubODE]''' : moteur physique développé par Ubit Umarov pour OpenSimulator, basé sur le moteur physique [https://fr.wikipedia.org/wiki/Open_Dynamics_Engine ODE (Open Dynamics Engine)].
-* [http://opensimulator.org/wiki/BulletSim '''BulletSim'''] : BulletSim est un module pour OpenSimulator qui crée la physique du monde virtuel en utilisant [https://fr.wikipedia.org/wiki/Bullet_(moteur_physique) le Moteur physique Bullet]. Bullet semble ne plus être maintenu.
+* [http://opensimulator.org/wiki/BulletSim '''BulletSim'''] : BulletSim est un module pour OpenSimulator qui crée la physique du monde virtuel en utilisant [https://fr.wikipedia.org/wiki/Bullet_(moteur_physique) le Moteur physique Bullet].
 * [https://fr.wikipedia.org/wiki/Havok_(moteur_de_jeu) '''Havok''']  est le moteur physique propriétaire utilisé par Second Life.
 * [https://fr.wikipedia.org/wiki/PhysX '''PhysX'''] est un moteur physique en temps réel,  propriété de Nvidia sous licence BSD-3.
-* 🏗️
+* [https://www.bepuentertainment.com/ '''BEPUphysics'''] est une bibliothèque de physique 3D gratuite, open source, écrite entièrement en C. BEPUphysics a une liaison pour C#.
+* [https://jrouwe.github.io/JoltPhysics/ '''JoltPhysics''' ] : est un moteur de physique de jeu multi-cœur. JoltPhysics a une liaison pour C#.
+* [https://fr.wikipedia.org/wiki/CryEngine '''CryEngine'''] : est un moteur de jeu développé par Crytek sous licence propriétaire, spécialisé dans les jeux de tir à la première personne.
 === Discussion ===
 * Joe Magarac dit  qu'il existe maintenant une décomposition convexe approximative. Un certain chevauchement est autorisé, ce qui induit moins de cas problèmes.
 * Ubit Umarov dit que la décomposition convexe n'est  pas recommandée pour la physique dans OpenSim. Le moteur physique UbODE n'utilise pas de décomposition convexe. Bullet fait sa propre décomposition. Il souligne que la physique n'est pas lié à la vue.
+* Bullet semble ne plus être maintenu bien que Cuga Rajal précise que Bullet reçoit encore des mises à jour et qu'il est passé à une nouvelle version il y a un an. Mais, même si Bullet n'était plus maintenu, ce n'est pas grave, car d'après Ubit Umarov, la physique simple n'a pas changé .
 * Il semble que Second Life s'éloigne de Havok pour explorer d'autres options.
-* C# a des liaisons pour au moins deux autres moteurs physiques, comme par exemple PhysX (propriété de Nvidia), il suffit d'ajouter des modules dans OpenSim pour pouvoir les utiliser. Mais, c'est plus facile à dire qu'à faire.
+* C# a des liaisons pour d'autres moteurs physiques, comme par exemple PhysX (propriété de Nvidia), BEPUphysics et JoltPhysics , il suffit d'ajouter des modules dans OpenSim pour pouvoir les utiliser. Mais, c'est plus facile à dire qu'à faire.
-* D'après Ubit Umarov, le niveau d'ouverture actuel et futur du code de PhysX est incertain. Il ajoute que beaucoup de jeux finissent par utiliser leurs propres moteurs  physique.
+* D'après Ubit Umarov, le niveau d'ouverture actuel et futur du code de PhysX est incertain. Il ajoute que beaucoup de jeux finissent par utiliser leurs propres moteurs  physique. Unreal qui utilisait PhysX utillise maintenant son propre moteur physique Chaos. Unity utilise PhysX.
-* 🏗️
 = Viewers=