Varregion/fr

Retour au Sommaire

Languages:

English    Deutsch    Español    Français    日本語    Монгол    Português

"Varregion" est un dispositif d'OpenSimulator qui permet d'installer des régions d'une taille supérieure à 256x256. La région sera simplement plus grande, elle se comportera comme une région normale avec des frontières plus éloignées.L'implémentation de ce dispositif utilise le protocole de l'extension des grandes régions de Aurora . Aussi, les versions actuelles des viewers Firestorm et Singularity utilisées par Aurora seront également compatibles avec les varregions d'OpenSimulator.Les varregions sont différentes des Megaregions, ancien dispositif d'installation de grandes régions. Les mégarégions ne nécessitent pas de viewer particulier ( avec des fonctions non mises en œuvre par Linden Lab) mais elles reposent sur un certain nombre de hacks fragiles mis en place pour utiliser les viewers d'une manière que Linden Lab n'avait pas prévue. Les mégarégions contiennent également un certain nombre de bogues côté simulateur.Une liste croissante de modifications sont mises en oeuvre par le Protocole Varregion pour implementer les"varregions".

Restrictions

Quelques restrictions s'appliquent :

• les dimensions des régions doivent être un multiple de 256 et être inférieures ou égales à 8192.
• la région doit être carrée (à partir du 04 novembre 2013).
• Les régions adjacentes doivent avoir la même taille. Par exemple, vous pouvez avoir plusieurs régions de 512x512 l'une à côté de l'autre (et voir dans l'autre région transfrontalière). Il semble y avoir un problème au niveau des viewers. Si des régions de taille différentes sont à portée de vue, des crashes se produisent. Prévoyez d'avoir des régions de même taille dans la même "vue". Rappellez-vous que les coordonnées d'une région sont référencées sur une base de 256 mètres. Ainsi un groupe de quatre régions de 512x512 aurait par exemple pour coordonnées 8000/8000, 8000/8002, 8002/8000 et 8002/8002.
• Vous devez utiliser BulletSim (depuis le 04 novembre 2013, ODE n'a pas été mis à jour pour les varregions.)
• Vous devez utiliser l'implémentation des cartes de niveaux (heightmap) de BulletSim. Depuis le 28 janvier 2014, BulletSim a été modifié pour forcer le chargement des heightmap des terrains si la taille des régions est supérieure à 256 sur un côté. La configuration peut être forcée en ajoutant à vos fichiers INI :

 [BulletSim]
   TerrainImplementation = 0

Configuration

La taille des régions est indiquées dans le fichier Region.ini :

   [MyRegionName]
   RegionUUID = 95ec77ec-58c5-4ce2-9ff3-b6d1900d78a2
   Location = 1000,1000
   SizeX = 1024
   SizeY = 1024
   InternalAddress = 0.0.0.0
   InternalPort = 9200
   AllowAlternatePorts = False
   ExternalHostName = SYSTEMIP

• Si la taille n'est pas spécifiée, bien entendu, elle sera par défaut définies à 256x256.
• Si les dimensions renseignées ne respectent pas les restrictions, des valeurs acceptables seront calculées et des messages d'alerte et d'erreur seront envoyés dans le log.
• Si vous convertissez une mégarégion, n'oubliez pas de placer dans votre configuration :

CombineContiguousRegions = false

Pour que la fonction llRezObject fonctionne au-delà de 256 mètres écrivez dans la section [Xengine] de Opensim.ini (pour une région de 512mx512m)

ScriptDistanceLimitFactor = 512.0

• La heightmap est enregistrée dans la base de données sous la forme d'un tableau de 'shorts" (deux octets), aussi, si vous avez une très grande région vous pourriez avoir besoin d'augmenter la taille maximum dans la base de données . Par exemple, une région de 2816x2816 (11x11 régions normales) va utiliser une heightmap de 56 mo. Pour MySQL, vous devrez définir max_allowed_packet à quelque chose comme 64M (fichier /etc/mysql/my.cnf pour Ubuntu).

Charger un terrain

Les commandes de console habituelles fonctionnent pour les varregions. Si vous avez configurer une grande régions , vous pouvez charger des fichiers de heightmap BMP/RAW/PNG avec les dimensions de la région et couvrir l'ensemble du terrain. Par exemple, une région de 1024x1024 sera complètement initialisée après le chargement de "1024.bmp" si "1024.bmp" est un bitmap de 1024x1024.

Varregions et les fichiers OAR

Les objets et les terrains sont stockés dans des fichiers OAR comme si c'était une seule région. Cela signifie que si vous avez sauvegardé une région de 1024x1024 dans un fichier OAR, vous pourrez plus tard restaurer les objets et le terrain sur une région de 1024x1024. Si vous chargez le fichier OAR d'une plus petite région dans une région plus grande, l'espace de terrain non spécifiée est par défaut de 256 mètres.

Pour rendre la conversion vers varregions plus facile, la commande 'load oar' a un nouveau paramètre '--displacement "<x,y,z>. Cela déplace tous les objets et le terrain à partir du fichier oar quand vous le chargez dans la nouvelle région.

Par exemple, disons que vous disposez de quatre régions adjacentes de 256x256 (aor00.oar, aor01.oar, aor10.oar, aor11.oar). Vous créez une nouvelle varregion de 512x512 nommée 'grosseregion'. Les commandes suivantes vont placer les objets, les terrains et les parcelles des quatres régions dans la nouvelle varregion :

change region grosseregion
load oar oar00.oar
load oar oar01.oar --displacement "<0,256,0>" --merge --forceterrain --forceparcel
load oar oar10.oar --displacement "<256,0,0>" --merge --forceterrain --forceparcel
load oar oar11.oar --displacement "<256,256,0>" --merge --forceterrain --forceparcel

Notez la présence des nouveaux paramètres "--forceterrain" and "--forceparcel". Le paramètre "--merge" utilisé par lui-même, sert à fusionner les objets des multiples OARs. La fusion supprime aussi le chargement des données du terrain et des informations des parcelles . C'est ce qu'on veut quand on fusionne les objets. Mais si vous chargez des OARs multiples pour créer une nouvelle région plus grande, les informations du terrain et des parcelles devront aussi être chargées. D'où l'utilité des nouveaux paramètres.

Les problèmes connus

Cette modification majeure d'OpenSimulator touche un nombre important de domaines. Les chapitres qui suivent présentent les modifications que Justin CC a du faire.

Données du terrain

Un des problèmes majeur a été de passer les données des terrains à la pile de protocoles. L'implémentation existante passait un tableau de floats qui représentaient un tableau de 256x256 hauteurs de terrain. La classe TerrainChannel ne peut pas être passée dans la pile des protocoles (llClienView) parce que TerrainChannel n'est pas défini comme faisant partie de OpenSim.Region.Framework et donc n'est pas visible par le code du protocole.

La solution choisie par JustinCC a été de créer une classe TerrainData dans OpenSim.Framework. TerrainData englobe simplement la structure des données pour le terrain et ajoute des attributs pour définir les dimensions X et Y.

Il ne voulait pas changer la signature de IClientAPI parce que beaucoup de modules externes en dépendent. IClientAPI aurait dû être modifié pour passer TerrainData plutôt qu'un float[]. JustinCC a décidé de ne pas changer IClientAPI, il a fait en sorte que LLClientView ignore le passage du tableau. À la place il l'a fait remonter dans la scène associée pour récupérer l'instance TerrainData.

Il existe une sous-classe de TerrainData: HeightmapTerrainData qui enregistre le terrain sous forme de heightmap compressée. La hauteur de chaque point est un "short" qui correspond à height * compressionFactor où compressionFactor est habituellement égal à "100". Cela crée un enregistrement compact des hauteurs de terrain avec deux décimales de résolution après la virgule.

Le LLLP ("Linden Lab Legacy Protocol") envoie les données de hauteur de terrain dans un "patches" compressé d'une surface 16x16 de hauteur de terrain. Cette partie du protocole est implémentée dans TerrainChannel. JustinCC pense que les optimisations de protocoles sous-jacents ne doivent pas apparaître dans la pile, ainsi il a essayé de cacher les tâches du terrain dans TerrainData. Il veut signifier par là qu'un jour la création des terrains en meshs sera généralisée. Et il ajoute, "n'est-ce pas ?".

Le terrain dans la base de données

Auparavant les heightmaps des terrains étaient enregistrées dans la base de données avec le type BLOB sous la forme d'un tableau de doubles de 256x256. Pour avoir des régions de tailles différentes, ce format a dû changer. Il y existe un champs dans la base de données actuelle qui stocke le temps auquel le terrain a été sauvegardé. Cette information n'est pas utilisée, ainsi ce champs a été choisi pour contenir le champs des blob des hauteurs issues de la refonte du code.

Il y a trois formes de blob de carte de niveaux : héritée, 2D compressée et 2D régulière. La carte de niveau par héritage correspond, bien sûre, à la collections précédentes de 256x256 doubles. La carte 2D régulière contient les dimensions X, Y suffisamment de floats pour les hauteurs de cette région. La carte 2D compressée contient les X et Y et compressionFactor suivie d'assez de "shorts" pour la carte de hauteur.

Le format par héritage est utilisé par défaut pour lire et écrire dans la base de données, si la région a des dimensions de 256x256, elle sera stockée au format hérité. Ceci pour conserver une compatibilité descendante.

Tous les modules de base de données (MySQL, SQLite, MSSQL et PSQL) ont été modifiés pour stocker les terrain de cette façon.

Détection du passage des frontières

La majeure partie du code de "passage vers une nouvelle région" est basé sur le contrôle des frontières. Il y a aussi pas mal de code pour calculer si un objet ou un avatar a traversé la limite d'une région et autant pour calculer l'adresse de la prochaine. L'introduction d'une taille de région variable chamboule beaucoup ces calculs. Cela signifie que le code chargé habituellement de faire ces calculs définit l'adresse de la nouvelle région et la localisation d'arrivée en se basant sur une taille constante de 256x256m. Avec les varregions ces hypothèses ne tiennent plus. L'implémentation d'une varregion signifie que le calcul de l'adresse de la région d'origine et de la localisation des frontières va être déplacé vers le service de grille GridService, entité qui connaît réellement la taille de toutes les régions.

La réalisation du calcul de localisation des régions qui est vraiment une opération GridService a conduit JustinCC a extraire complétement le code de vérification des limites de la grille pour le remplacer par deux fonctions : Scene.PositionIsInCurrentRegion(Vector3 pos) et ensuite EntityTransferModule.GetRegionContainingWorldLocation(double X, double Y). L'ancienne fonction teste si un objet / avatar est sorti de la région courante pour ensuite trouver la région de destination.(Side note: GetRegionContainingWorldLocation should really be a function on IGridService but that exercise is left for future hacking).

These changes leave all the 'border' code in limbo -- the generation of the border lists is still there but it is not being used. This should eventually be cleaned up. Also, the computation of neighbor regions is scattered around with routines on IGridService, in EntityTransferModule and a bunch of bookkeeping in Scene. This too should be cleaned up.

Notes d'implémentation

Depuis le 27 Janvier 2014 varregion est une caractéristique du 'master' de la branche de référence.

Travail à faire

Ce qui suit sont des notes qui concernent des domaines que JustinCC jugent nécessaires d'être travaillés.

• Consolider le code de calcul des régions voisines (Scene, EntityTransferModule et IGridService ont tous un code 'détecter le voisin').

(la suite n'a pas été traduite.)