Ortho4XP

[Oscar Pilote]

En faite c'est bon j'ai réussi à trouver la solution!

Bravo, je venais de tester la -16-069 et cela fonctionnait, j'allais t'écrire que je ne voyais
ce qui pouvait te cause le problème.
@+

[fabien]

Tu veux dire que si tu mets w2xp au dessus d'une ancienne tuile Simheaven tu n'as pas de scintillement ?
Ou bien juste Simheaven tout seul (ce qui correspondrait à Ortho4XP + yOrtho4XP_Overlays) ?
Je suis curieux de tes retours sur les différentes combinaisons.
A mon avis le scintillement ne peut en rien être lié au maillage et aux orthos, mais il est lié au nombre
important d'objets, de petite taille, situés loin. Pour le réduire tu peux augmenter LOD (si tu utilises
Real Terra Haze c'est le paramètre en bas) ou bien augmenter l'antialiasing (si ta carte est suffisamment
pêchue pour le supporter...).

Pour ton problème de LFML, plutôt que faire une mise à jour qui plantera autre-chose (mon fichier source est en chantier)
je te propose la chose facile suivante : tu ouvres le fichier Ortho4XP.py avec un bon éditeur de texte (genre gedit, pas un type word
ou que sais-je qui va ajouter plein de ******rie cachée dans le fichier ou casser l'identation) et tu commentes les lignes
numéro 1540 1541 1542 (tu peux les voir sur la dropbox, elles commencent toutes les 3 par "vertices",
tu rajoutes un dièse devant les v de chacune (-> #vertices ....), tu sauves et tu relances les étapes.
Tu peux ensuite remettre l'original.

Bonsoir Oscar,

J'ai voulu refaire la tuile +43+005 que j'avais supprimée mais, contrairement à la 1ère fois, où j'avais suivi tes consignes ci-dessus, je n'ai pas réussi cette fois (piste toujours accidentée sur LFML). J'ai pourtant bien réinséré le signe "#" juste devant les 3 "vertices", mais sans succès. Pourrais-tu m'aider stp ?

D'autre part, pour cette même tuile, n'y a-t-il pas moyen de faire quelque chose au niveau de Marseille car, bizarrement, la colorimétrie n'est pas du tout la même sur la ville phocéenne que sur le reste de la tuile ? Merci d'avance.

[fabien]

Bonsoir Oscar,

J'ai voulu refaire la tuile +43+005 que j'avais supprimée mais, contrairement à la 1ère fois, où j'avais suivi tes consignes ci-dessus, je n'ai pas réussi cette fois (piste toujours accidentée sur LFML). J'ai pourtant bien réinséré le signe "#" juste devant les 3 "vertices", mais sans succès. Pourrais-tu m'aider stp ?

D'autre part, pour cette même tuile, n'y a-t-il pas moyen de faire quelque chose au niveau de Marseille car, bizarrement, la colorimétrie n'est pas du tout la même sur la ville phocéenne que sur le reste de la tuile ? Merci d'avance.

Précision utile : pour le point 2, le fournisseur est "bing"

[Oscar Pilote]

Bonsoir Fabien,

Suite au problème que tu avais eu j'ai ajouté en haut du fichier Ortho4XP.py rajouté l'option
"tile_has_water_airport".
Par défaut elle est à False, si un problème tel celui de LFML survient (le lissage de l'eau et de l'aéroport interfèrent),
tu le mets à True avant de relancer Ortho4XP et il n'interfèreront plus. Ensuite tu peux remettre à False (tu peux
tenter aussi de laisser tout le temps à True, mais tu auras moins de lissage des plans d'eau).

Concernant Marseille "en jaune". Je suis aussi embêté que toi (le problème est présent aussi sur Rennes sur une tuile
zonephoto que j'ai uploadée, et sur quelques autres grandes métropoles. Bing met à jour ces zones en proposant des
résolutions plus fortes, mais la colorimétrie est différente du reste. Si quelqu'un possède des BI (peu importe le ZL)
de Rennes et Marseille d'avant la jaunification je suis preneur (surtout en vue de zonephoto).

[Mclnight]

Bonsoir Fabien,

Suite au problème que tu avais eu j'ai ajouté en haut du fichier Ortho4XP.py rajouté l'option
"tile_has_water_airport".
Par défaut elle est à False, si un problème tel celui de LFML survient (le lissage de l'eau et de l'aéroport interfèrent),
tu le mets à True avant de relancer Ortho4XP et il n'interfèreront plus. Ensuite tu peux remettre à False (tu peux
tenter aussi de laisser tout le temps à True, mais tu auras moins de lissage des plans d'eau).

Concernant Marseille "en jaune". Je suis aussi embêté que toi (le problème est présent aussi sur Rennes sur une tuile
zonephoto que j'ai uploadée, et sur quelques autres grandes métropoles. Bing met à jour ces zones en proposant des
résolutions plus fortes, mais la colorimétrie est différente du reste. Si quelqu'un possède des BI (peu importe le ZL)
de Rennes et Marseille d'avant la jaunification je suis preneur (surtout en vue de zonephoto).

Salut il me semble que j'ai encore des orthophoto de l'alpha 2, pas sûr que Marseille soit dans le tas, mais je peux vérifier, pour ce faire il me faudrait le script que tu as mentionné l'autre fois, qui devait reclasser les ortho.
Aussi pour Marseille, je me suis inspiré du message précédent et j'ai tagué, dans OSM, l'étang de Bolmon (la partie de l'étang de berre qui reste en ortho de couleur verte) pour pouvoir l'intégrer dans la liste sea_equiv

[Glah_Salamanthe]

Bizarreries de fonctionnement d'Ortho4XP … (est-ce une erreur de ma part ? )
J'ai réinstallé Ortho4XP sur un nouveau disque USB3 de 3 To , place qu'il partage avec X-Plane !
J'en ai profité de prendre la toute dernière version dans laquelle j'ai transféré toutes mes anciennes données (élévations, textures déjà téléchargées , …)

je me suis lancé dans la fabrication des tuiles de la Suisse en zoom 16 et 17 pour les zones couvrant des aérodromes.
J'ai conservé le même réglage pour toutes mes tuiles . Tout se passe bien jusqu'à l'étape 3 qui a l'air de se passer elle aussi correctement …
Dans la fenêtre d'avance des "travaux" je peux lire toute la litanie :

Downloading missing orthophoto 45632_69008_BI17.jpg Converting orthophoto to build texture 45696_69136_BI17.dds.
Downloading missing orthophoto 45616_69056_BI17.jpg
Converting orthophoto to build texture 45632_69008_BI17.dds.
Downloading missing orthophoto 45584_69072_BI17.jpg
Converting orthophoto to build texture 45616_69056_BI17.dds.

…mais au final, surprise : le dossier des textures de la tuile est … vide !!! (enfin presque , il ne contient que les png des masques ) et la tuile pèse entre 100 et 600 Mo !

Pourtant dans le dossier "Orthophos" les données graphiques sont bien là : pour chaque tuile il y a environ 1,5 Go de données réparties en deux dossiers : "BI_16" et "BI_17"

… et étonnamment, la tuile "zOrtho4XP_+47+008", réalisée au milieu de toutes les autres est correcte !! allez comprendre ??

__________________________________


Autre problème : la fonction "Build Overlay"
J'ai bien les données de AlPilot "zz XP10_HD_Mesh_V3" que j'ai téléchargées, décompressées et organisées par latitudes et longitudes dans un sous dossier "Earth nav data"

Quand je lance la fonction "Build Overlay" après avoir désigné le dossier "zz XP10_HD_Mesh_V3", je n'obtiens … rien !
voilà le résultat :

Independent Step : Building of an Overlay DSF from third party data : -------------------


-> Making a copy of the original overlay DSF in tmp dir
-> The original DSF is a 7z archive, uncompressing...
-> Converting the copy to text format
Converting ./tmp/+47+007.dsf from DSF to text as ./tmp/tmp_dsf.txt
File ./tmp/+47+007.dsf had 0 ter, 0 obj, 0 pol, 0 net.
Converted ./tmp/+47+007.dsf to ./tmp/tmp_dsf.txt
-> Expurging the mesh and the beach polygons from the text DSF
-> Converting back the text DSF to binary format
Converting ./tmp/tmp_dsf_without_mesh.txt from text to DSF as ./tmp/tmp_dsf_without_mesh.dsf
Scanning for dimension properties...
ERROR: the DSF boundaries are out of range. This can indicate a missing or corrupt sim/dimension properties.
ERROR: Error convertiong ./tmp/tmp_dsf_without_mesh.txt to ./tmp/tmp_dsf_without_mesh.dsf
-> Coping the final overlay DSF in ./yOrtho4XP_Overlays/Earth nav data/+40+000


Completed in 1.04sec.

[Oscar Pilote]

Bizarreries de fonctionnement d'Ortho4XP … (est-ce une erreur de ma part ? )
J'ai réinstallé Ortho4XP sur un nouveau disque USB3 de 3 To , place qu'il partage avec X-Plane !

…mais au final, surprise : le dossier des textures de la tuile est … vide !!! (enfin presque , il ne contient que les png des masques ) et la tuile pèse entre 100 et 600 Mo !

C'est parce que la version de ma dropbox utilise maintenant nvcompress et plus imagemagick (convert) pour la conversion jpeg vers dds.
La compression d'imagemagick n'était pas entièrement supportée par x-plane, ce qui engendrait des petits carrés pas très esthétiques dans
certaines zones de couleur presque uniforme.
Pour les utilisateurs Mac il y a deux dossiers compressés contenant nvcompress dans Utils (l'un contient une version qui marche avec cuda et l'autre sans (tout le monde
n'a pas une carte nvidia)). Il faut dézipper celui désiré et indiquer son chemin complet dans la variable "convert_cmd_bis" (en haut du fichier Ortho4XP.py).
Je donnerai des instructions plus détaillées lorsque cela aura été testé par suffisamment d'utilisateur mac (ou de manière plus probable : Milan mettra
à jour son manuel mac quand j'aurai pris le temps avec lui de tester la chose (plusieurs utilisateurs du .org l'utilise déjà cependant)).

Pour tes overlays le problème vient sans doute de ton 7z, décompresse les en amont si tu ne veux pas te casser la tête (ou lis le tuto de Milan je crois qu'il
a déjà intégré cela, il faudra que je refasse le point avec lui à son retour d'Asie).

[temium62]

Pareil que toi Gla Salamanthe. J avais posté il y a quelques posts le même problème il y a des tuiles que j ai dû refzire en etape 3 car je n avais pas vérifié et en lancant XP il plantait.
Je ne sais pas a quoi cela est dû mais a priori hier ca fonctionnait... Mystère !!!

[Patbest]

Bizarreries de fonctionnement d'Ortho4XP … (est-ce une erreur de ma part ? )
J'ai réinstallé Ortho4XP sur un nouveau disque USB3 de 3 To , place qu'il partage avec X-Plane !
J'en ai profité de prendre la toute dernière version dans laquelle j'ai transféré toutes mes anciennes données (élévations, textures déjà téléchargées , …)

je me suis lancé dans la fabrication des tuiles de la Suisse en zoom 16 et 17 pour les zones couvrant des aérodromes.
J'ai conservé le même réglage pour toutes mes tuiles . Tout se passe bien jusqu'à l'étape 3 qui a l'air de se passer elle aussi correctement …
Dans la fenêtre d'avance des "travaux" je peux lire toute la litanie :
Downloading missing orthophoto 45632_69008_BI17.jpg Converting orthophoto to build texture 45696_69136_BI17.dds.
Downloading missing orthophoto 45616_69056_BI17.jpg
Converting orthophoto to build texture 45632_69008_BI17.dds.
Downloading missing orthophoto 45584_69072_BI17.jpg
Converting orthophoto to build texture 45616_69056_BI17.dds.
…mais au final, surprise : le dossier des textures de la tuile est … vide !!! (enfin presque , il ne contient que les png des masques ) et la tuile pèse entre 100 et 600 Mo !

Pourtant dans le dossier "Orthophos" les données graphiques sont bien là : pour chaque tuile il y a environ 1,5 Go de données réparties en deux dossiers : "BI_16" et "BI_17"

… et étonnamment, la tuile "zOrtho4XP_+47+008", réalisée au milieu de toutes les autres est correcte !! allez comprendre ??

__________________________________


J'ai eu la même chose et en réinstallant "nvcompress" tout est rentré dans l'ordre.

[jojo64]

Même problème pour moi. Du coup j'ai supprimer la commande "nvcompress"pour remettre l'ancienne "imagemagick" et ca refonctionne.
Cela dit, je vais tester l'astuce d'oscar:

Pour les utilisateurs Mac il y a deux dossiers compressés contenant nvcompress dans Utils (l'un contient une version qui marche avec cuda et l'autre sans (tout le monde
n'a pas une carte nvidia)). Il faut dézipper celui désiré et indiquer son chemin complet dans la variable "convert_cmd_bis" (en haut du fichier Ortho4XP.py).

[temium62]

Pour moi ca semble fonctionner en ayant rechargé les fichiers Dropbox tout frais !

[Glah_Salamanthe]

Pour tes overlays le problème vient sans doute de ton 7z, décompresse les en amont si tu ne veux pas te casser la tête

Il me semblait qu'ils étaient décompressés : ils arrivent au format ".zip" et ceux que j'ai dans mon dossier sont au format ".dsf"

Le format ".dsf" est-il encore une compression ?

[Oscar Pilote]

Le format ".dsf" est-il encore une compression ?

Un fichier peut avoir une extension qui est sans rapport avec ce qu'il contient.
Dans le cas présent oui les fichiers .dsf du HD mesh sont 7zippés à la base, tu peux les décompresser en leur laissant le même nom
(ça prend un peu plus de place sur le disque mais ça en accélère le chargement par X-Plane qui doit sinon le faire en direct).

[pvalsecc]

Hello,

J'ai essayé de générer une tuile +46 +006 z17 GO2. Ortho4xp le fait sans messages d'erreur une fois qu'on a augmenté curv_tol à 0.4. Mais si on essaye de voler un peu dans la zone, on voit des tas de carrés blancs.

J'ai essayé de relancé la génération, il met des tes de messages comme quoi les fichiers sont déjà là.

En comptant les jpg présents dans Orthophotos/+46+006/GO2_17/, je n'en trouve que 786 au lieu des 816 d'une autre zone.

J'ai trouvé un example de fichier manquant (46384_68000_GO217.jpg) en copiant les logs dans mon éditeur préféré et je cherchant 46384_68000, je ne trouve rien. Donc on dirait qu'Otho4xp n'essaye même pas de le charger.

J'utilise la version que j'ai downloadée hier soir sur dropbox.

J'ai regardé un peu le code et il y a un gros truc suspect. Ce genre de pattern est suicidaire:

texture=download_to_do_list[0]
... #truc qui prend du temps
download_to_do_list.pop(0)

Bref, il y a de très grandes chances que plusieurs threads prennent la même texture, mais en suppriment des différentes de la liste.

Puis-je suggérer de faire comme ça:

texture=download_to_do_list.pop(0)
... #truc qui prend du temps

D'ailleurs c'est déjà fait comme ça à d'autres endroits.

Après avoir changé ça et relancé la génération de la tuile, j'ai toujours le problème, mais bon, c'est déjà un début... Je vais continuer a chercher la prochaine fois que j'ai du temps.

Merci pour ce merveilleux soft et A+

[sixberas]

Bonjour
Beau travail et ce n'est pas fini !
Petit pb avec Dinard qui est"corrompu" et ne peut être décompressé
Cordialement