Réunion du 30-07-2024

De OSWiki
Aller à la navigation Aller à la recherche

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

Ajout d'une commande terrain save-tile-ext

  • Le problème actuel de la 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 qui existe déjà, elle enregistre une heightmap dans un fichier plus grand. L'exemple donné pour la commande de console concerne cette commande :
terrain save-tile 3 3 999,999

Ici on sauvegarde une région de taille 256 à la coordonnée 999,999 au centre d'un fichier 768x768 pixels, 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. Il faut donc encore écrire 999 pour centrer l'image, car elle génère un tout nouveau système de coordonnées qui n'est pas basé sur 256 régions, mais sur 768.

NDLR  :

Ce que j'ai compris mais, c'est peut-être complètement faux  : 

terrain save-tile <diviseur_x> <diviseur_y> <coordonnée_x> <coordonnée_y>
  • <diviseur_x> et <diviseur_y> : représentent le nombre de divisions que vous souhaitez effectuer sur le terrain dans les directions horizontale et verticale. Dans l'exemple, 3 signifie que le terrain de 768 m x 768 m sera divisé en 3 tuiles de 256 m x 256 m.
  • <coordonnée_x> <coordonnée_y> : représentent les coordonnées globales de la région dans la grille. Dans l'exemple, pour la région de 256x256 les coordonnées sont 999,999 alors que celles de la région de 768 sont 1000,1000. En utilisant "999 999" , on décale la région d'un point en diagonale ce qui met la région 256 au milieu d'un fichier 768x768. Cela signifie que, comme tout est basé sur la taille de la région, on ne peut pas 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.


  • La fonction ajouté 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).

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

Source

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

Récupérée de « https://cogito.no-ip.info/cogito/OSWiki/index.php?title=Réunion_du_30-07-2024&oldid=9909 »