Partir du Mesh pour obtenir les données .hgt ?

[Glah_Salamanthe]

Bonsoir tous …

Grâce au merveilleux travail de Oscar et ses Ortho4XP, il est possible à partir de données d'élévation (.hgt) d'obtenir des Mesh de qualité pour nos tuiles photos .

Ma question est la suivante : est-il possible de faire l'inverse ? à partir d'un Mesh de reconstituer des données d'élévation .hgt ? et si oui, comment ?

La raison ?

Tant pour la scène "Cervin" (où le problème est réglé, Fabio Bellini ayant fourni les patches nécessaires) que pour les Dolomites, Frank Dainese le concepteur principal a modifié le Mesh d'origine .

Afin d'avoir des parois verticales de très bonne qualité visuelle et d'éviter un étirement de l'image comme on l'a dans une orthophoto, Frank a construit ses montagnes sous forme d'objets ! pouvant ainsi plaquer des images-photo sur les parois verticales, comme pour un bâtiment.
Mais pour que ces "montagnes-objets" reposent correctement à leur place, il a modifié le Mesh et créé dans les zones de ces montagnes des "à plat". Sur lesquels reposent les "montagnes-objets".

Si vous voulez créer une tuile photo pour cette scène , elle va intégrer le vrai mesh et n'aura pas des fameux "à plat" . Résultat : les montagnes-objets vont se poser par dessus , au sommet des montagnes de votre Mesh : elle flotteront dans les airs !
Il faudrait donc construire sa tuile photo en utilisant le Mesh corrigé de Frank de façon à intégrer les "à-plat" !
D'où la nécessité d'extraire SES données d'élévation à partir de son Mesh …

[Oscar Pilote]

Les DSF créés par Meshtool contiennent les données d'élévation en brut à un endroit bien déterminé à l'intérieur du DSF.
Pour les récupérer tu peux faire :
DSFTool -dsf2text le_nom_du_fichier_dsf_dé7zippé_si_besoin.dsf ton_nom_préféré.txt (DSFTool est un des utilitaires des xptools disponibles sur le site de Laminar)
En plus de mettre les commandes du dsf au format texte (dont tu te moques ici), tu obtiendras un fichier d'élévation .raw (raw = brut) et aussi éventuellement un fichier de bathymétrie.
Tu peux utiliser le .raw d'élévation directement dans le champs custom_dem d'Ortho4XP.

-----
Ortho4XP possède une autre fonctionnalité qui pourrait aussi être utilisée ici (encore faut-il vérifier que le Cervin modélisé ne possède pas de surplombs) : celle de faire confondre le mesh localement avec un .obj donné (un exemple dans la dropbox avec le .obj de Méribel de Jean-Marie; Jasum pourrait aussi te montrer son intégration de l'aiguille du midi). Dans ce cas l'objet ne vient plus se poser de guingois en conflit avec le mesh mais s'emboîte exactement dessus (ce qui permet entre autre d'éviter de rendre l'objet solide, car ça coûte assez cher à X-Plane)

[AIME43]

Oscar tu peux me donner la formule pour récupérer directement les données du .raw altitudes, je l'ai pour les .hgt mais je trouve pas pour .raw.
Merci par avance.

[Oscar Pilote]

Qu'est-ce que tu endends par la formule ? Les altitudes sont encodées comme dans un .hgt (2 bytes par point, sans entêtes) à la seule différence que l'ordre des bits est inversé (tu lis les 2 bytes, tu fais un byteswap, ensuite tu lis comme un int16)

[AIME43]

C'est la formule du byteswap que j'arrive pas à faire correctement.

[Glah_Salamanthe]

Un très grand merci Oscar, je vais donc me lancer et vous tiendrai au courant

(DSFTool est un des utilitaires des xptools disponibles sur le site de Laminar)Tu peux utiliser le .raw d'élévation directement dans le champs custom_dem d'Ortho4XP.

Utilisé de nombreuses fois déjà, ne devrait donc pas poser de problèmes .

rendre l'objet solide, ça coûte assez cher à X-Plane

Pas si sûr !
En 2016, j'avais fait l'acquisition de "CZST-Stewart" de "BETI-X" !
Dans leur scène, tous les bâtiments sont construits en "solide" ! Afin de vérifier, j'avais repris l'ensemble de leur bâtiments (.obj) et supprimé la particularité "en dur" afin de supprimer le test de collision pour X-Plane.
Je n'avais alors pas remarqué (dans mes conditions d'emploi) une grande différence de FPS entre l'une ou l'autre version .

[AIME43]

Qu'est-ce que tu endends par la formule ? Les altitudes sont encodées comme dans un .hgt (2 bytes par point, sans entêtes) à la seule différence que l'ordre des bits est inversé (tu lis les 2 bytes, tu fais un byteswap, ensuite tu lis comme un int16)

Oscar tu peux me donner la formule à utiliser, j'y bourre

[Glah_Salamanthe]

Un très grand merci Oscar !

Enfin les DOLOMITES comme je les espérais !

Explications et images à venir !

[PhM]

C'est la formule du byteswap que j'arrive pas à faire correctement.

Pour un 16 bits : Inverser les deux paquets de 8 bits qui le compose, par exemple (pas forcement optimal) :

- Lire le 16 bits dans une variable.
- Masquer l'octet de poids fort avec une opération ET bitwise avec 0x00FF (en C : & 0x00FF) pour garder l'octet de poids faible.
- Le décaler vers les poids forts (en C : << 8).
- Relire le 16 bits dans une autre variable.
- Masquer l'octet de poids faible avec une opération ET bitwise avec 0xFF00 (en C : & 0xFF00) pour garder l'octet de poids fort.
- Combiner les deux avec une opération OU bitwise (en C : | )

PhM

[AIME43]

Merci PhM, c'est sympa
Mais c'est bien ce que j'avais trouvé comme solution, mais cela me donne des nombres à 5 chiffres !!

[PhM]

... mais cela me donne des nombres à 5 chiffres !!

Tu parles de nombres en décimal, pas en binaire ?

En décimal un nombre 16 bits non signé va de 0 à 65535, un nombre signé va de -32768 à 32767, ce sont tous des nombres à cinq chiffres au maximum.

PhM

[AIME43]

Oui le résultat en nombres décimal.
Et dire que pour les fichiers .hgt ça marche, avec une formule légèrement différente.

[PhM]

Oui le résultat en nombres décimal.
Et dire que pour les fichiers .hgt ça marche, avec une formule légèrement différente.

Tant que tu ne donneras pas d'info sur ce qui marche, également mieux expliquer le problème et donner la formule qui marche je ne pourrais pas faire plus.

PhM

[AIME43]

pour les fichiers HGT:
Dim buffer.b(1)
value = ((buffer(1) & $FF) | (buffer(0) << 8) )

pour les fichiers RAW x-plane:
buffer.w
value = (((buffer & $00FF) << 8) ) | ((buffer & $FF00) >> 8)

Merci de ta sollicitude

[PhM]

Le but est de changer l'endianness d'un nombre de 16 bits non signé, de big endian vers little endian ou réciproquement. Le langage utilisé n’étant pas précisé je vais donc me baser sur des hypothèses, je vais supposer que :

• buffer.b est un tableau de nombres de 16 bits non signés comprenant deux éléments.
• buffer.w est un nombre de 16 bits non signé.

pour les fichiers HGT:
Dim buffer.b(1)
value = ((buffer(1) & $FF) | (buffer(0) << 8) )

Dans ce cas si mon hypothèse est valide tu essayes de faire un nombre de 16 bits à partir de deux autres nombres de 16 bits. Ce n'est pas ce que l'on souhaite faire, ce serait plutôt :

value = ((buffer.b(0) & $00FF) | (buffer.b(0) << 8) )

On peut faire le << sans masquer puisque lors d'un décalage, arithmétique ou logique, les bits de poids faible seront mis à zéro.

pour les fichiers RAW x-plane:
buffer.w
value = (((buffer & $00FF) << 8) ) | ((buffer & $FF00) >> 8)

Dans ce cas, si buffer.w est bien le nombre à convertir alors c'est celui qu'il faut utiliser, en reprenant la même ligne cela donne :

value = (((buffer.w & $00FF) << 8) ) | ((buffer.w & $FF00) >> 8)

Avec cette écriture il est primordial que buffer.w soit non signé, dans le cas contraire le >> va propager le bit de signe et mettre tous les bits de poids fort à 1, ce qui n'est pas du tout ce que l'on souhaite.

PhM