Ortho4XP

[Mirage34]

J'aurais bien une petite demande, à l'occasion d'une prochaine évolution.

Serait-il possible à la réalisation d'une tuile, d'avoir un fichier log qui renseigne sur la date et les paramètres de réglage de réalisation de la tuile, avec éventuellement les durées de chaque phase (ou abandon) ? Ce fichier pourrait d'ailleurs être commun à toutes les tuiles lancées.

Juste cette idée lorsque l'on fait plusieurs fois la même tuile pour s'y retrouver parmi les différents réglages.

Par avance, Merci oscar.

;)


PS : Avec GO2, j'ai pas mal de problème de tuiles bleues. Je crée en ZL17, ce qui ne devrait pas poser - à priori - de problème. Voici ce que cela donne :


Constatez-vous aussi cette difficulté ?

[Mirage34]

Bonjour à tous

Je m'interroge sur le fonctionnement de l'option sea source / sea source level.

Dans ma tuile (+43+003) j'affecte BI en base source avec un ZL17. Pour Sea source j'applique FRortho avec un ZL de 18.

Si je prends comme référence Frontignan, la bande de terre entre l'étang d'Ingril et la méditerranée, voici la tuile 95872_133824_FRorth18.dds qui a été crée :



Or dans Xplane, j'ai cela :



ce qui correspond en fait à la tuile de BI ici :



J'aurais pensé que la source de la tuile cotière aurait du être celle de FRortho. Or pour mon fichier DDS, j'ai bien le nom de FRortho mais avec l'image de BI... Aucun autre fichier de la même tuile qui viendrait de BI dans le répertoire textures.

Où est le soucis ?

Merci pour votre aide.

[Oscar Pilote]

Or pour mon fichier DDS, j'ai bien le nom de FRortho mais avec l'image de BI... Aucun autre fichier de la même tuile qui viendrait de BI dans le répertoire textures.

Je n'ai pas compris, ta première image c'est bien un dds FRorth avec une image FRorth.
Indépendamment de cela, l'étang en question ne doit pas être considéré 'sea' dans OSM, donc sea_source ne sera pas utilisé pour lui (pour la partie mer, si).
Tu peux utiliser sea_equiv pour faire passer l'étang en zone 'sea' si tu veux.

Pour ta question sur 'GO2', il faut fréquemment changer le "v=***" dans l'adresse, comme je n'utilise pratiquement que les fournisseurs
nationaux je ne m'en rends pas compte, mais tu peux changer directement dans Carnet_d_adresses.py (si tu hésistes j'ai fait un post
il y a quelques jours sur le .org pour montrer comment avec httpfox)

[Mirage34]

ta première image c'est bien un dds FRorth avec une image FRorth.

Oui, je confirme. Cette première image est celle qui se trouve dans le répertoire textures créé par ortho4XP.

Indépendamment de cela, l'étang en question ne doit pas être considéré 'sea' dans OSM

J'imagine cela bien volontier, la partie mer doit être considérée comme sea.

, donc sea_source ne sera pas utilisé pour lui (pour la partie mer, si).

Là, je ne comprends pas. Cela veut-il dire que pour ce type d'image, la partie "terre" de l'image est crée à partir du jpeg du fournisseur de base (BI en l'occurrence) et la partie "sea" est crée à partir du jpeg du fournisseur sea_source ? Si c'est le cas, pour moi la mer Xplane recouvre la mer du fichier sea_source (voir screen ci-dessous).


En tout état de cause, comment Xplane peut-il afficher des images qui ne sont pas dans le répertoire "textures" ??? Dans les 2 screens qui suivent, aucune des images qui constituent cette scène ne proviennent de FRortho, toutes sont issues de BI.





Et voici la liste de mon répertoire textures de Ortho4XP ainsi que le fichier de configuration (mis sous forme de txt pour être accepté ici)

Le fichier en question est le 95872_133824_FRorth18.dds.

Pour bien se comprendre, c'est la seule tuile que j'ai dans Xplane, même pas de "global scenery".



====================================
PS

En fait, je viens de m'apercevoir que dans toutes les tuiles crées, celles qui sont côtières en ZL 18 (FRortho) existent aussi en ZL17 par BI.

Exemple :

48016_66784_BI17.dds qui recouvre :
- 96032_133568_FRorth18.dds
- 96032_133584_FRorth18.dds
- 96048_133584_FRorth18.dds

Du coup, les ZL18 doivent ne pas être pas affichées au profit des ZL17...

[Oscar Pilote]

Là, je ne comprends pas. Cela veut-il dire que pour ce type d'image, la partie "terre" de l'image est crée à partir du jpeg du fournisseur de base (BI en l'occurrence) et la partie "sea" est crée à partir du jpeg du fournisseur sea_source ?

Oui.

Si c'est le cas, pour moi la mer Xplane recouvre la mer du fichier sea_source (voir screen ci-dessous).

Comme dans tous les cas de figure, c'est à cela que servent les masques (et le tien est un peu mince pour
la source FRortho qui accepte à coup sûr 16 et souvent 32 voire 64) car les textures mers cessent d'exister à une
certaine distance des côtes, il faut donc gérer la transition.

En tout état de cause, comment Xplane peut-il afficher des images qui ne sont pas dans le répertoire "textures" ??? Dans les 2 screens qui suivent, aucune des images qui constituent cette scène ne proviennent de FRortho, toutes sont issues de BI.

Non, on voit bien en haut à droite le long de la plage les "vagues" blanchâtres de la texture FRortho.

En fait, je viens de m'apercevoir que dans toutes les tuiles crées, celles qui sont côtières en ZL 18 (FRortho) existent aussi en ZL17 par BI.

Exemple :

48016_66784_BI17.dds qui recouvre :
- 96032_133568_FRorth18.dds
- 96032_133584_FRorth18.dds
- 96048_133584_FRorth18.dds

Du coup, les ZL18 doivent ne pas être pas affichées au profit des ZL17...

Si, cfr ci-dessus.

[Mirage34]

Ok, merci Oscar, j'ai globalement compris le fonctionnement.

Comme dans tous les cas de figure, c'est à cela que servent les masques (et le tien est un peu mince pour
la source FRortho qui accepte à coup sûr 16 et souvent 32 voire 64) car les textures mers cessent d'exister à une
certaine distance des côtes, il faut donc gérer la transition.

Donc là, tu parles de la valeur "Mask_width". Je l'ai laissée par défaut à 8. Je vais faire des essais avec différents étagements.

;)


PS :
Voici le résultat avec une valeur de Mask_width à 64 :


On voit bien la partie mer qui est en FRortho.

[Odevillée]

Ok, merci Oscar, j'ai globalement compris le fonctionnement.

Même tuile avec BI zl16 mask=160

[Mirage34]

merci Odevillée.

Mon Post Scriptum et ta réponse se sont croisés. Je n'avais pas compris l'influence de ce paramètre mask_width.

Maintenant c'est très clair, je poursuis mes tests.

;)

PS : je profite pour reposer une question que j'avais peut-être déjà évoquée : Est-il possible de ne créer qu'une partie de tuile pour faire des tests plus rapidement ?

[Oscar Pilote]

Est-il possible de ne créer qu'une partie de tuile pour faire des tests plus rapidement ?

Ca depend de ce que tu veux faire, si tu as déjà les dds ça ne devrait prendre que 2 minutes environ, sinon choisis par exemple
un ZL de base en ZL14 (voire moins) et en custom zl pour la zone qui t'intéresse, ça dépendra alors juste de la taille de ta zone
et du zl choisi, la base en ZL14 se fera très rapidement.

[Mirage34]

si tu as déjà les dds ça ne devrait prendre que 2 minutes environ

C'est un peu le problème. Comme je ne connais pas les relation entre vector data, mesh, masks et Tile, et entre les différents paramètres avec ces étapes du traitement, pour éviter toute erreur je refais tout de nouveau. Clairement, le plus long, c'est la création des tuiles : les dds. Donc si on les a déjà et que l'on modifie un des paramètres de l'une des étapes précédentes, je pense qu'il y a lieu de refaire l'intégralité des dds. Non ?

Sinon, effectivement, ça fait gagner du temps, mais comment d'éventuelles modif (comme la variation de Masks_width ou Ratio_water) s'implémente-t-elle si on ne reconstruit pas les dds de zéro ?

[Oscar Pilote]

Donc si on les a déjà et que l'on modifie un des paramètres de l'une des étapes précédentes, je pense qu'il y a lieu de refaire l'intégralité des dds. Non ?

Non, il y a trois types de données dans un tuile finie :
1) les dds de texture
2) les png des masques
3) le fichier .dsf et les fichiers .ter (qui sont tous deux des fichiers de commandes, rien à voir avec des images)

Les seuls paramètres qui modifient la conversion jpeg=>dds (et donc le 1)) ce sont ceux de correction colorimétrique (brightness_adjust,saturation_adjust,
contrast_adjust ou full_color_correction). Si tu ne changes pas cela les dds existants seront conservés à l'identique.
Les seuls paramètres qui modifient les masques (le paquet 2)) sont masks_width (plus de nouvelles options plus avancées que j'omets ici) et un éventuel changement du trait de côte au Step 1, si les données OSM évoluaient, qui se reflèterait d'abord dans le .poly du Step 1, de-là dans le .mesh du Step 2, et finalement dans les fichiers png de masques.
Tout le reste (quel triangle prend quelle texture, quel niveau de transparence etc) est du domaine logiciel et n'entre in fine que dans les .dsf et .ter (donc le paquet 3)).

[Mirage34]

Je prends bonne note de tout cela et je m'organise en conséquence pour ne relancer que le strict nécessaire.

Juste un point complémentaire :
- Si l'on change de fournisseur, à priori les données OSM, le mesh et le mask ne changent pas donc on peut ne relancer que le step 3 car seuls les dds de texture changent eux (dès lors que les jpg du founisseur correspondant ont été téléchargés).
- Le changement du ZL en revanche nécessite de relancer les steps 2, 2.5 et 3 à minima.

[Oscar Pilote]

Que le Step 3 même avec changement de ZL et/ou ajout de Custom zoomlevel.

[Nono15]

Bonjour à tous,

Je ne sais pas si c'est ici que je dois mettre mon message. Si ce n'est pas le cas dites le moi que je puisse solliciter de l'aide au bon endroit.

Je viens de me mettre tout récemment à X-Plane avec la version 11 beta après de longues heures sur FS depuis plus de 30 ans et P3D plus récemment.

J'ai également découvert ce super outil : Ortho4XP qui me permet de me faire des scènes supers (merci Oscar) que j'habille avec un autogen grâce à World2Xplane.

J'ai repris quelques endroits d'Amérique du Nord (Grand Canyon, Yellowstone) qui sont magnifiques. J'ai aussi commencé avec la France où j'ai fait de magnifiques scènes. Je mixe Z16 et 17 pour un meilleurs résultat.
J'ai commencé avec la version 1.19r2 et maintenant je suis en version 1.20. La 1.19r2 avait été installé de manière traditionnelle avec Python et lancé par son script Python. Pour la 1.20 j'ai utilisé l'exécutable Windows mais un problème est apparu lorsque j'ai voulu faire la tuile +45+002 où se trouve le lac de Bort les Orgues et avec le script Python j'ai la même chose. J'obtiens un lac vide, tout du moins avec l'eau qui doit se trouver à environ 500 pieds au dessous le niveau de son bord normal. Comme si le barrage avait été vidé sauf que les flancs de montagnes sont abruptes. Je récupère les niveau d'élévation sur le site Global Data Explorer car en n'utilisant pas de niveau élévation et en laissant ortho4XP le faire, il me dit qu'il manque des tuiles d'élévation sur ce qu'il récupère automatiquement. A quelques kilomètres de là il y a le lac de Neuvic qui lui sort correctement.
J'ai essayé avec ou sans l'option "Use masks for inland" et ça fait pareil.

Mon soucis :


A quelques kilomètre de là le lac de Neuvic qui lui semble correcte :


Malheureusement je suis plus utilisateur que développeur pour bien comprendre ce qui m'arrive. Mais je ne demande qu'à apprendre.

Merci par avance pour votre aide.

[Glah_Salamanthe]

Bonjour à tous,
Je ne sais pas si c'est ici que je dois mettre mon message. Si ce n'est pas le cas dites le moi que je puisse solliciter de l'aide au bon endroit.

Bonjour et bienvenue Nono15 !

Non, non, ton message est semble-t-il à la place correcte …
… mais comme il s'agit de ton premier message , il aurait été agréable au préalable de passer par le post "présentation"
Merci !