Réunion du 30-07-2024

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

Heightmap

Chargeur de terrain Tiff

• Présentation du chargeur Tiff pendant la réunion du 23 juillet 2024
• Vincent Sylvester a implémenté les niveaux de gris 16 bits. Cela signifie que chaque pixel peut avoir 2^16 (soit 65 536) valeurs différentes. La commande terrain save-tile vérifie toujours la profondeur de bits et utilise ce qui est trouvé, donc supporte également les anciens 8 bits, mais pour le TIFF, il sauvegardera les nouveaux fichiers en 16 bits, ce qui permet un terrain de 4096 en hauteur au cas où on en aurait besoin.
• Il faut encore nettoyer un peu le code et le tester pour voir si le chargement est robuste. Dans l'ensemble, ça avance. Il faut faire plus de tests et corriger les erreurs, mais c'est mieux que d'essayer de trouver comment convertir RAW32.
• TIFF 16 bits peut être chargé dans Gimp sans aucun plugin, il supporte nativement ce type et peut également être sauvegardé dans ce format. Cela signifie que convertir des heightmaps existantes en TIFF et charger des hautes montagnes devient plus facile.
• La résolution verticale de la heightmap va affecter la qualité et le niveau de détail du terrain. Les niveaux de gris de 16 bits permettent une grande précision. Vincent Sylvester a réduit les niveaux de gris à 4096 pour faciliter la visualisation puisque le traitement de l'image ne nécessite pas la pleine gamme de 65 536 niveaux.
• Conversion (du niveau de gris ?) en hauteur (ndlr : j'indique la ligne de code ici mais je n'en sais pas plus).

(ushort)((valeur - minHeight) * 65535 / (maxHeight - minHeight)) ;

La valeur est décalé de 256 mètres vers le haut, donc le terrain à la limite inférieure de -100 ne devrait pas être traité.

• La sauvegarde et le chargement n'entraînent aucune modification de l'aspect du terrain.

Ajout d'une commande terrain save-tile-ext

Le problème de sauvegarde des heightmap

• On peut charger un terrain avec un déplacement mais , on ne peut pas l'enregistrer avec un déplacement. On ne peut pas non plus enregistrer une région plus grande dans un fichier plus petit. Supposons qu'on veuille diviser une région 6x6 en 2x2, on ne peut le faire qu'au chargement, ce qui peut être gênant.

NDLR  : Une région 6x6 correspond à une région de 256*6 x 256 * 6, c'est à dire 1536x1536. C'est la même chose pour une région 2x2 qui correspond à une région 512x512. Je pense que l'idée de sauvegarder un terrain pour une autre dimension / agencement est une bonne idée. Ainsi, il est plus simple d'enregistrer plusieurs versions d'un terrain au moment de sa création, en les nommant en fonction des caractéristiques de chaque sauvegarde, plutôt que de se compliquer la vie plus tard en essayant de se souvenir pourquoi, comment et où nous avons utilisé la heightmap. Ensuite, il faudrait charger l'OAR et risquer de se tromper plusieurs fois avant d'obtenir le résultat souhaité.

La commande terrain save-tile

• Cette commande existe déjà. Elle enregistre une heightmap dans un fichier plus grand. L'exemple donné au début de la réunion par Vincent Sylvester concerne cette commande :

terrain save-tile <nom_du_fichier> 3 3 999 999 

Ici on sauvegarde une région de taille 256 aux coordonnées 999,999 au centre d'un fichier 768x768 pixels de coordonnées 1000x1000, on décale la région d'un point en diagonale. Il n'y a aucun moyen de sauvegarder cette même région au centre d'une image de 512 pixels, parce que le système est basé sur les tuiles et non sur les mètres. Une tuile correspond à la taille d'une région, quelle que soit cette taille, donc si la région a une taille de 768, il en sera de même pour chaque tuile. Comme tout est basé sur la taille de la région, cela signifie qu'il n'est pas possible de sauvegarder un fichier de 256 dans une image de 512 et le décaler pour que l'île soit au milieu parce que la plus petite tuile est 256.

terrain save-tile
Sauvegarde la heightmap actuelle dans un fichier le plus grand.
= Paramètres =
* filename (Chaîne)
        Le fichier dans lequel vous souhaitez enregistrer, l'extension du fichier détermine le chargeur à utiliser. Les extensions prises en charge sont les suivantes .png (PNG)
* Largeur du fichier (Entier)
        La largeur du fichier en carreaux (un carreau a la taille de la région)
* Hauteur du fichier (Entier)
        La hauteur du fichier en carreaux (un carreau a la taille de la région)
* tuile X minimale (Entier)
        La coordonnée X de la région de la première tuile du fichier.
* tuile Y minimale (Entier)
        Les coordonnées Y de la région de la première tuile du fichier. 
= Exemple =
Pour enregistrer un fichier PNG pour un ensemble de tuiles de carte de 3 régions de large et 3 régions de haut à partir des coordonnées de la carte (9910,10234)
        # terrain save-tile ST06.png 3 3 9910 10234

La commande terrain save-tile-ext

• La commande ajoutée par Vincent Sylvester terrain save-tile-ext, permet d'indiquer la taille du fichier en pixels / mètres, le décalage et la partie de la région à sauvegarder si par exemple on veut diviser une région de 512 en 4 plus petites.
• Prototype de la fonction dans le code OpenSim :

SaveFile(ITerrainChannel map, string filename, int fileWidth, int fileHeight, int startX, int startY, int stopX, int stopY, int offsetX, int offsetY).

NDLR  : La commande de console devrait être appelée ainsi (c'est une déduction et pas une certitude ) : terrain save-tile-ext fileName fileWidth fileHeight startX startY stopX stopY offsetX offsetY Paramètres : * filename (Chaîne) Fichier enregistré. Il s'agit du nom du fichier dans lequel la heightmap sera sauvegardée. * fileWidth (entier) Largeur du fichier de sortie en pixels. Cela détermine la largeur de l'image qui sera générée à partir de la zone du terrain spécifiée. * fileHeight (entier) Hauteur du fichier de sortie en pixels. Cela détermine la hauteur de l'image qui sera générée à partir de la zone du terrain spécifiée. * startX (entier) Coordonnée X du coin inférieur gauche de la zone à sauvegarder. Cela représente la position horizontale de départ dans le terrain, avec l'origine située en bas à gauche. * startY (entier) Coordonnée Y du coin inférieur gauche de la zone à sauvegarder. Cela représente la position verticale de départ dans le terrain, avec l'origine située en bas à gauche. * stoptX (entier) Coordonnée X du coin supérieur droit de la zone à sauvegarder. Cela représente la position horizontale de fin dans le terrain. * stopY (entier) Coordonnée Y du coin supérieur droit de la zone à sauvegarder. Cela représente la position verticale de fin dans le terrain. * offsetX (entier) Décalage horizontal à appliquer lors de la sauvegarde. Cela peut être utilisé pour ajuster la position de la zone sauvegardée par rapport à l'origine. * offsetY (entier) Décalage vertical à appliquer lors de la sauvegarde. Cela peut être utilisé pour ajuster la position de la zone sauvegardée par rapport à l'origine. Exemple : sauvegarder une région de 256x256 au centre d'une heightmap de 512x512 (à vérifier ne prenez pas cela pour argent comptant !). terrain save-tile-ext "mon_image.png" 512 512 0 0 256 256 128 128

Commande pour charger et déplacer un terrain

• Ubit Umarov trouve que terrain save-tile-ext n'est pas utile et qu'il existe déjà des options pour charger et déplacer l'OAR d'une région. Dans terrain save-tile les coordonnées globales n'ont pas d'importance. Les heigmaps ont 0,0 au coin inférieur gauche normal, le point de référence pour une région. Le seul problème est que pour importer, il faut connaître la taille de la région et avec quelques notions de mathématiques.

load oar [-m|--merge] [-s|--skip-assets] [--default-user "Nom d'utilisateur"] [--merge-terrain] [--merge-parcels] [--mergeReplaceObjects] [--no-objects] [--rotation degrés] [--bounding-origin "<x,y,z>"] [--bounding-size "<x,y,z>"] [--displacement "<x,y,z>"] [-d|--debug] [<chemin OAR>]

Charge les données d'une région à partir d'une archive OAR.

    --merge : fusionne l'OAR avec la scène existante (supprime le chargement des informations sur le terrain et les parcelles).
        Options avec --merge :
            --merge-terrain : charge également le terrain, remplaçant l'original.
            --merge-parcels : charge également les parcelles, en les fusionnant avec l'original.
            --mergeReplaceObjects : si la scène contient un objet avec le même identifiant, le remplace. Sans cette option, le chargement de cet objet est ignoré.
    --skip-assets : charge l'OAR mais ignore les ressources qu'il contient.
    --default-user : utilise cet utilisateur pour tout objet dont le propriétaire a un UUID non trouvé dans la grille.
    --no-objects : supprime l'ajout de tout objet (utile pour charger uniquement le terrain).
    --rotation : spécifie la rotation à appliquer à l'OAR. Spécifiée en degrés.
    --bounding-origin : ne placera que les objets qui, après déplacement et rotation, tombent dans le cube englobant dont la position commence à <x,y,z>. Par défaut, c'est <0,0,0>.
    --bounding-size : spécifie la taille du cube englobant. La valeur par défaut est la taille de la région de destination et ne peut pas être plus grande que cela.
    --displacement : ajoutera cette valeur à la position de chaque objet chargé.
    --debug : force l'archiver à afficher des messages sur l'emplacement de chaque objet.

Le chemin peut être soit un emplacement sur le système de fichiers, soit une URI. Si cela n'est pas spécifié, la commande recherche un OAR nommé region.oar dans le répertoire courant. [--rotation-center "<x,y,z>"] était une option, mais elle ne fait plus rien et sera bientôt supprimée.

Lorsqu'un OAR est chargé, les opérations sont appliquées dans cet ordre :

    Rotation (autour du centre de la région de l'OAR entrant)
    Découpage (un cube englobant avec origine et taille)
    Déplacement (définir les coordonnées de décalage dans la région de destination)
 

Viewers

Sharpview

• Nouvelle version de Sharpview qui permet d'obtenir des jonctions correctes entre les régions. https://animats.com/sharpview/releases/release-0.9.0.html. Si vous trouvez des régions qui n'ont pas de jonctions correctes, faites-le savoir à Joe Magarac.

Divers

• Certains viewers ont du mal à gérer les régions de 768x768. Plusieurs ne fonctionnent qu'avec des tailles qui sont des puissances de 2 comme 256, 512, 1024, 2048.

Source

http://opensimulator.org/wiki/Chat_log_from_the_meeting_on_2024-07-30