Ortho4XP: relief sur le Méridien de Greenwich à Tarbes LFBT

[jasum]

Ok ceci explique cela.

Pour le moment, la seule solution que je n'ai pas testé, est de convertir le relief de la partie de aéroport en .obj, raccorder les partie des deux tuiles, faire les raccord proprement avec un utilitaire 3D, et renvoyer le tout à ortho4XP. Mais j'avoue qu'envoyer le relief sur un utilitaire 3D proprement, je n'y arrive pas... Et de toute façon, pas sûr que ca marche...

J'ai dejà fait celà, je vais essayer pour la zone de LFBT, je te tiens au courant.

[robster]

Morphée ayant été plus fort, je n'avais pas eu le temps d'essayer la tuile SASPlanet (@robster, il n'y a pas d'ajout de SASPlanet dans Ortho4XP), mais le résultat n'est pas probant

Avec l'option flatten, pas de soucis.

Mais sans l'option flatten :
Sans tuile SASPlanet

Avec tuile SASPlanet



Probablement que certain avions comme les Jardesign vont partir en sucette sur ces zones vides.





Je vais aussi essayer la méthode @jasum

@robster, il n'y a pas d'ajout de SASPlanet dans Ortho4XP.
Ok merci

[ailgorbot]

Je viens d'essayer également, Oui curvature_tol=1.0 ne donne pas mieux

Reste la dernière approche avec le patch OSM sur la zone.

[Oscar Pilote]

J'essaie de regarder cela ce soir, je ne sais pas si j'arriverai encore à me servir du programme :-)

[jasum]

Pour le moment, la seule solution que je n'ai pas testé, est de convertir le relief de la partie de aéroport en .obj, raccorder les partie des deux tuiles, faire les raccord proprement avec un utilitaire 3D, et renvoyer le tout à ortho4XP. Mais j'avoue qu'envoyer le relief sur un utilitaire 3D proprement, je n'y arrive pas... Et de toute façon, pas sûr que ca marche...

Salut Jojo64

J'ai édité le mesh dans Blender depuis les wavefronts extraits du mesh, modifié quelques triangles et construit les patch Obj8, d'abord un patch couvrant la totalité de LFBT avec une origine sur la +43-001 le résultat n'était pas satisfaisant, puis j'ai scindé en deux patchs Obj8 correspondant à chaque tuile donc patch Obj8 sur +43+000 et un sur +43-001 le resultat me semble satisfaisant.
Je te joins un zip contenant ces patchs les dossiers LFBT sont à placer comme un fichier patch.osm.

par exemple: Patches >> +40+000 >> +43+000 >> LFBT >> LFBT.obj

Si tu peux essayer, tiens-moi au courant.

[jojo64]

Reste la dernière approche avec le patch OSM sur la zone.

Déjà essayé, c'est encore pire.

Salut Jojo64
J'ai édité le mesh dans Blender depuis les wavefronts extraits du mesh, modifié quelques triangles et construit les patch Obj8, d'abord un patch couvrant la totalité de LFBT avec une origine sur la +43-001 le résultat n'était pas satisfaisant, puis j'ai scindé en deux patchs Obj8 correspondant à chaque tuile donc patch Obj8 sur +43+000 et un sur +43-001 le resultat me semble satisfaisant.
Je te joins un zip contenant ces patchs les dossiers LFBT sont à placer comme un fichier patch.osm.
par exemple: Patches >> +40+000 >> +43+000 >> LFBT >> LFBT.obj
Si tu peux essayer, tiens-moi au courant.

Super merci beaucoup, je teste ça et je reviens vers toi.
Il faudra vraiment qu'un jour j’apprenne à faire ça moi même, c'est quand même super pratique!

J'essaie de regarder cela ce soir, je ne sais pas si j'arriverai encore à me servir du programme :-)

Rho, c'est comme le vélo, ça ne s'oublie pas!!!
Merci Oscar, j'attends tes recommandations!

[jojo64]

Petit aparté pour Oscar:

Peut être tu es déjà au courant, dans ce cas oublie ce message!
Je rappel que je suis sur Mac.

C'est la première fois que j'utilise les .obj sous forme de patch.
A ma première tentative, "assemble vector...", Ortho4xp s'arrête au moment de prendre le patch .obj en compte.
Dans mon terminal, j'ai cet erreur:

UnicodeDecodeError: 'utf-8' codec can't decode byte 0x80 in position 3131: invalid start byte

J'ai déjà vu ce message, en fait ce sont les fichiers .DS_store, qu'utilisent MacOsx pour mémoriser la forme de ces dossiers, et qui sont cachés sur OSX, qui posent problèmes, car ils sont lu par Ortho4xp, d'où le message d'erreur.
Je sais faire pour les supprimer, et dans ce cas ça marche implacable.
Je pense que la solution sera d'imposer à Ortho4xp de lire seulement les fichier .obj, sinon ça plante sur Mac.

De mon coté ca ne me pose pas de problème, maintenant que je le sais, je vais me dépatouiller avec.
Mais au moins, si dans un avenir incertain tu venais à utiliser OSX, ou si quelqu'un te pose le problème, comme ça tu es au courant!
Salutations!

Fin de l’aparté!

[jojo64]

J'ai édité le mesh dans Blender depuis les wavefronts extraits du mesh, modifié quelques triangles et construit les patch Obj8, d'abord un patch couvrant la totalité de LFBT avec une origine sur la +43-001 le résultat n'était pas satisfaisant, puis j'ai scindé en deux patchs Obj8 correspondant à chaque tuile donc patch Obj8 sur +43+000 et un sur +43-001 le resultat me semble satisfaisant.
Je te joins un zip contenant ces patchs les dossiers LFBT sont à placer comme un fichier patch.osm.
Si tu peux essayer, tiens-moi au courant.

Et bien non, j'obtiens plus ou moins le même résultat qu'avec un patch classique, pour dire que c'est pire que sans patch du tout.
Dommage, j'y ai cru pendant un moment! Merci quand même d'avoir pris le temps de m'aider!

[papet30]

Bonsoir,
toutes mes tuiles sont générées avec Ortho4XP V130 et des DTM à 20m, je ne vois pas vraiment de problème de raccordement de tuiles sauf un aspect visuel qui vient principalement , je pense, plutôt de la différence des orthophotos en bordure.
Mais peut être que je me trompe.

[jojo64]

Bonsoir,
toutes mes tuiles sont générées avec Ortho4XP V130 et des DTM à 20m, je ne vois pas vraiment de problème de raccordement de tuiles sauf un aspect visuel qui vient principalement , je pense, plutôt de la différence des orthophotos en bordure.
Mais peut être que je me trompe.

Je l'ai déjà expliqué plus haut, il faut désactivé l'option "always flatten" de la scène que tu utilises, sinon la scène aplatit le relief au chargement, ce qui corrige le problème, mais en créer un autre plus loin.

[jasum]

Et bien non, j'obtiens plus ou moins le même résultat qu'avec un patch classique, pour dire que c'est pire que sans patch du tout.
Dommage, j'y ai cru pendant un moment! Merci quand même d'avoir pris le temps de m'aider!

C'est curieux, je n'ai pas cela.
Je te joins le mesh des 2 tuiles

https://www.dropbox.com/s/5s9rvbtwecfy71x/Mesh.7z?dl=0

[Oscar Pilote]

Les indications qui auraient pu mettre sur la voie :

création de la +43-001 : Step 1 dit LFBT 1 runway
création de la +43+000 : Step 1 dit LFBT boundary
-> bien que la piste déborde sur les deux tuiles, elle n'est prise en compte que pour la 1ère.

Explications :
La personne qui a encodé dans OSM a mis à la fois le bord de la piste et le centre de la piste (rien d'anormal et très courant).
Seulement son bord de piste déborde pas mal sur les taxiways avec des espèces de bras de part et d'autre.
Du coup Ortho4XP repère que la piste n'est pas suffisamment rectangulaire et utilise un rectangle générique
basé sur la ligne du centre de piste (rien d'anormal non plus).
Problème : la ligne de centre de piste est entièrement contenue dans la +43-001, elle n'est donc pas vue dans la +43+000 (et donc comme il n'a ni un polygone de bord de piste suffisamment rectangulaire, ni une ligne centrale, il ne fait pas d'auto-patch sur la +43+000, seulement un lissage sur toute la surface de l'aéroport.

Solutions possibles :
1) ouvrir les deux fichiers airports de OSM_data correspondant à ces deux tuiles dans JOSM, sélectionner le centre de piste sur la +43-001 (il y a deux morceaux), faire copier, passer sur la +43+000 et faire "coller à la position originale" (nécessite mode expert dans les options JOSM). Sauver et relancer la tuile +43+000. Testé et fonctionne (uniquement chez celui qui le fait).
2) modifier OSM en ligne et rendre la piste plus rectangulaire ( = retirer ces drôles de bras qui débordent sur les taxiways). Comme ce bord déborde sur les deux tuiles la modif sera prise en compte chez tous les utilisateurs. (pas testé)
3) attendre une mise à jour qui aille cherche les données OSM un tout petit peu plus loin que le bout de la tuile.

Dans la même veine : le traitement des taxiways dans v130 attend des taxiways sous forme de lignes ou l'avion roule, pas des bords de taxiway. Donc là aussi il faut modifier dans OSM_data lorsque l'auteur OSM a choisi d'encoder les bords plutôt que le centre (s'il y a les deux et que le bord est encodé en multipolygone c'est ok, mais si comme ici il n'y a que le bord en multipolygone ce n'est pas pris en compte).

Autre chose à laquelle faire attention : pour un aéroport qui déborde de part et d'autre de la tuile, pour que le lissage ne donne pas des résultats différents de part et d'autre il faut que les données d'élévation "débordent" de la tuile (d'au moins autant que apt_smoothing_pix). C'est fait automatiquement avec les données viewfinderpanorama par défaut (elles sont recollées entre elles avant traitement), mais si tu utilises des données custom qui ne débordent pas (par exemple Sony) tu risques de faire face à des problèmes.

[papet30]

Je l'ai déjà expliqué plus haut, il faut désactivé l'option "always flatten" de la scène que tu utilises, sinon la scène aplatit le relief au chargement, ce qui corrige le problème, mais en créer un autre plus loin.

Oui mais je supprime systématiquement "Flatten 1" dans apt.dat de tout les aeroports que j'utilise comme c'est le cas pour LFBT de Laminar.
Bons vols

[jasum]

Salut Oscar Pilote

Merci de ton expertise et de toutes ces explications.

D'autre part dans un post: https://forums.x-plane.org/index.php...omment=1721930

Quand pense-tu pouvoir publier ce code?

[jojo64]

C'est curieux, je n'ai pas cela.
Je te joins le mesh des 2 tuiles
https://www.dropbox.com/s/5s9rvbtwecfy71x/Mesh.7z?dl=0

C'est mieux, beaucoup mieux
Mais j'ai toujours un léger décollage des 2 tuiles sur la piste qui fait sursauter mon avion, mais c'est situé en extrême bout de piste où normalement personne n'ira rouler, d'autant plus qu'il n'y a pas de retournement ici.
Mais pour les taxis ça a l'air d'aller, une légère secousse mais rien de bien méchant, en tout cas ça ferai l'affaire.

Je ne comprend pas pourquoi chez moi, tes patchs .obj me font obtenir ce résultat, mais c'est encore une autre histoire.

Merci Jasum, si je n'obtiens pas mieux avec la solution d'Oscar, j'utiliserai tes mesh qui feront l'affaire.
Merci beaucoup de ton aide!