« Réunion du 30-07-2024 » : différence entre les versions

De OSWiki
Aller à la navigation Aller à la recherche
Ligne 4 : Ligne 4 :
==Chargeur de terrain Tiff==
==Chargeur de terrain Tiff==
===[[Réunion_du_23-07-2024#Chargeur_de_terrain_Tiff| Présentation du chargeur Tiff pendant la réunion du 23 juillet 2024]]===
===[[Réunion_du_23-07-2024#Chargeur_de_terrain_Tiff| Présentation du chargeur Tiff pendant la réunion du 23 juillet 2024]]===
=== Ajout d'une commande save-tile-ext  ===
=== 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.
* 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|fond=white |bord=green|message = <br>
{{NDLR|fond=white |bord=green|message = <br>
* Je ne sais pas si ''save-tile-ext'' est une commande ou si c'est une fonction dans le code OpenSim. Il est question aussi d'une fonction ''save-tile'' qui n'existe pas dans les commandes de console.La commande est
terrain save <chemin vers la sauvegarde de la heightmap >.
* 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.
* 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é.
* 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é.

Version du 2 août 2024 à 19:09

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

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 sauvegarde est basée sur les vraies coordonnées de la région save-tile.
  • Ajout d'un seuil pour ne sauvegarder qu'une partie de la région.
  • Exemple donné : save-tile 3 3 999,999 sauvegarderait une région de taille 256 à la coordonnée 1000,1000 au centre du fichier 768.
NDLR  :

Ce que j'ai compris (mais c'est peut-être complètement faux . Si un jour la commande est intégrée au code, on aura sans doute l'explication)  :

save-tile save-tile <diviseur_x> <diviseur_y> <x_center> <y_center>
  • <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 votre exemple, 3 signifie que le terrain de 768 m x 768 m sera divisé en 3 tuiles de 256 m x 256 m.
  • <x_center> et <y_center> : représentent les coordonnées du centre de la région à sauvegarder.


Commande pour charger et déplacer un terrain

  • Ubit Umarov trouve que save-tile n'est pas utile et qu'il existe déjà des options pour charger et déplacer l'OAR d'une région.
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)
 

Scripts

Base de données

Modules

Bugs

Tests

Projets en cours / Infos

Viewers

Sharpview

Source

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