Ortho4XP

[Oscar Pilote]

Les sorcières sont de sortie ;-)

Bon, quel micmac pour trois fois rien. Il n'y a aucun souci à avoir python2.7 et python3 sur le même ordi (c'est comme
avoir deux copies de X-Plane, l'espace requis en moins) il faut juste choisir laquelle va exécuter par défaut les fichiers .py si
rien n'est précisé.
Mais indépendamment de l'ordre du path il suffit sinon d'indiquer dans la commande le programme que tu veux
utiliser, par exemple C:\python34\python.exe Ortho4XP.py (à adapter en fonction du répertoire où est installé ton exécutable).
Ou bien il doit y avoir aussi sous Windows un truc du style "clic bouton droit "-> "ouvrir avec" / puis cocher "choisir
cette application par défaut pour ce type de fichier", non ?

De son côté pip doit être installé par défaut dans C:\python34\scripts ou quelque-chose dans le style.

On attendra encore un peu les photos de Schipol alors !

[atanorr]

Merci de ton aide Oscar,
j'essaie de chercher sur google pourquoi la fonction pip qui doit être par défaut 3.4.3 de python, ne fonctionne pas, exact c'est normalement dans /script , mais je ne comprends pas pourquoi je n'ai pas de répertoire scripts pourtant bien installé avec ton dossier install win=> msi python 3.4.3...
C'est juste inscroyable mes sorcières..
oui le souci que j'ai eu , c'est qu a l'ouverture d'une fenêtre de commande , je m'endoutait, c'est python 2.7 qui lance ton ortho , et donc plantage..

[atanorr]

Aide mémoire:

Supprimer bug python pip dans windows après plusieurs installations


Je pense que je peu chercher pendant longtemps... => http://www.swarley.me.uk/blog/2014/0...ry-corruption/

et voilà réparé ;-) ! = 4h de recherche... avec => https://technet.microsoft.com/en-us/.../bb897448.aspx et le lien ce dessus.

[atanorr]

Quand tu contournes un aéroport tu dois effacer un fichier temporaire? . ele .poly .asc ?

[Oscar Pilote]

Si tu l'as fait directement dans openstreetmap il faut effacer le OSM_aeroway_aerodrome
(qui contient l'information OSM), .poly (sinon tu zappes l'étape 1 et donc tu te bases sur les
anciennes données OSM), et .1.ele (sinon tu zappes l'étape 2, et donc aussi l'étape 1).

Dans la version beta il n'y aura que trois étapes :

1) construction des données OSM -> génère le .poly
2) construction du maillage -> génère le .mesh
3) construction du DSF avec les orthophotos -> génère le .dsf et plus globalement la tuile

Chaque étape se base uniquement sur le fichier construit à l'étape précédente, on peut donc ne faire que
la dernière étape si on dispose du .mesh, ou commencer à la deuxième si on dispose du .poly.
On pourra choisir aussi de démarrer à l'étape 1 même si on dispose des données correspondantes,
par exemple pour l'ajout d'un patch ou d'un aéroport sur OSM.

D'ailleurs, si tu veux aplanir un aéroport, tu peux te faire un patch, c'est aussi, voire plus, rapide
et tu ne risques pas de faire des bêtises sur OSM (j'en ai encodés qq'uns et il est parfois difficile de
savoir exactement où est la clôture, surtout pour les gros aéroports où il y a des zones d'industries
dont on ne sait pas si elles en font partie).
Avec un patch tu traces un gros pâté autour de l'aéroport et cela suffit (sauf en montagne où il faut
soigner le pâté).

[atanorr]

je viens de faire EBBR sur openstreetmap, donc Bruxelles, effectivement j'avais oublier d'effacer le fichier d'information OSM , et donc pour ça certainement que EBBR ne s'affichait pas au début de l'étape 1 ;)
je teste :D

==> Bingo ;) c'est nickel :D

[atanorr]

Il me reste à redéfinir les zones d'exclusions.. ;) car petits arbres le long des pistes ^^...

EBBR corrigé pour Ortho4XP

M A G N I F I Q U E !!!

4k Full Hd (faible taille pour Daniel )

[Odevillée]

Salut Odevillée,

Les images aériennes de Bing ne couvrent pas toute l'île à cet endroit (d'ordinaire elles débordent sur la mer
de quelques centaines de mètres, ici elles s'arrêtent sur terre!). Du coup lors du téléchargement des petites
vignettes, Bing t'envoies une erreur lorsque tu la demandes, et Ortho4XP plutôt que de planter la texture
met du blanc à la place de la vignette.

Deux manières d'y remédier :

1) tu tiens à rester avec Bing : repère l'orthophoto vérolée et corrige-la "à la main" (corrige le jpeg et vire le dds
correspondant, ensuite relance et il recréera le dds).

2) utilise la source 'SP' (instituo geografico nacional)...

1) pas d'image vérolée avec BI cela semble normal.

2) Ne fonctionne pas avec SP

Exception in thread Thread-112:
Traceback (most recent call last):
File "/usr/lib/python3.4/threading.py", line 920, in _bootstrap_inner
self.run()
File "/usr/lib/python3.4/threading.py", line 868, in run
self._target(*self._args, **self._kwargs)
File "./Ortho4XP", line 1977, in obtain_texture_row
fake_headers=fake_headers_construct(website)
File "<string>", line 102, in fake_headers_construct
UnboundLocalError: local variable 'fake_headers' referenced before assignment
Exception in thread Thread-113:
Traceback (most recent call last):
File "/usr/lib/python3.4/threading.py", line 920, in _bootstrap_inner
self.run()Exception in thread Thread-112:
Traceback (most recent call last):
File "/usr/lib/python3.4/threading.py", line 920, in _bootstrap_inner
self.run()
File "/usr/lib/python3.4/threading.py", line 868, in run
self._target(*self._args, **self._kwargs)
File "./Ortho4XP", line 1977, in obtain_texture_row
fake_headers=fake_headers_construct(website)
File "<string>", line 102, in fake_headers_construct
UnboundLocalError: local variable 'fake_headers' referenced before assignment
Exception in thread Thread-113:
Traceback (most recent call last):
File "/usr/lib/python3.4/threading.py", line 920, in _bootstrap_inner
self.run()
File "/usr/lib/python3.4/threading.py", line 868, in run
self._target(*self._args, **self._kwargs)
File "./Ortho4XP", line 1977, in obtain_texture_row
fake_headers=fake_headers_construct(website)
File "<string>", line 102, in fake_headers_construct
UnboundLocalError: local variable 'fake_headers' referenced before assignment

File "/usr/lib/python3.4/threading.py", line 868, in run
self._target(*self._args, **self._kwargs)
File "./Ortho4XP", line 1977, in obtain_texture_row
fake_headers=fake_headers_construct(website)
File "<string>", line 102, in fake_headers_construct
UnboundLocalError: local variable 'fake_headers' referenced before assignment

etc...

[Oscar Pilote]

2) Ne fonctionne pas avec SP

2) : oubli d'ajouter 'SP' dans une des 2 listes du carnet d'adresse, c'est corrigé (-> retélécharger Carnet_d_adresses.py)
[la version en ligne contient aussi une source 'SE' pour la Scandinavie, je ne sais plus si elle était dans les uploads précédents]

[Odevillée]

2) : oubli d'ajouter 'SP' dans une des 2 listes du carnet d'adresse, c'est corrigé (-> retélécharger Carnet_d_adresses.py)
[la version en ligne contient aussi une source 'SE' pour la Scandinavie, je ne sais plus si elle était dans les uploads précédents]

merci Oscar, mais SP c'est moooooche.

[Oscar Pilote]

merci Oscar, mais SP c'est moooooche.

¿Ma qué dices?

Assez inégal mais magnifique par endroits (je te soupçonne de ne pas aimer quand ce n'est
pas très contrasté et très saturé, mais tu peux changer cela avec les paramètres correspondants.

Autre possibilité : tu fais juste le petit ilôt avec SP et le reste avec BI

[Oscar Pilote]

Mais je ne comprends pas trop ce que tu vas gagner sans le dsftools ;) ? que pourrais tu y gagner? :D .. wait and see ...

Pour être très honnête, je considérais plus cela comme un cadeau/caprice/défi que j'avais envie de me faire, pensant
que le bénéfice pour l'utilisateur serait marginal (éviter d'écrire le dsf format texte sur disque (presque 1gb) et grappiller
qqs secondes par-ci par là).

Ce n'est pas encore totalement terminé (je n'ai pas encore intégré l'ajout des triangles de water_overlay) mais j'ai eu droit
à une très bonne surprise (après beaucoup de galères pour comprendre comment optimiser le remplissage des piscines et
aussi beaucoup de crashs x-plane tant que toutes les virgules n'étaient pas en place).

D'abord cela fonctionne. Ensuite et surtout, il avale sans problème des nbrs de triangles importants (là où dsftool rend l'âme avec un
bad_alloc). Je viens de faire la 45 6 avec curvature_tol = 1 (6.7 millions de triangles, 1.4 Gb au max de consommation de RAM
pendant le traitement (@Dobro), et 16 min pour créer la tuile en ZL16).
Résultats dans le jeu :
1) pas de ralentissement apparent (0.01 sec CPU, 0.007 GPU par frame sur mon matériel (récent))
2) je peux jeter mon ancienne vidéo de Chamonix à la poubelle (détails ++ des petites pointes le long des arêtes)
J'attends avec impatience que J. de Ferranti sorte le DEM à 10m pour tenter de faire monter encore l'addition (avec le DEM actuel
à 30m je pense que tout est déjà grappillé).

[Au passage je racontais des âneries concernant le nbr de triangles des mesh HD et UHD (en fait je répétais celles de DSFTool...) :
mesh HD = 1.5 millions environ, UHD = 3.5 millions environs. Cela relativise la comparaison que j'avais faite et que je referai donc
sur des bases plus justes]

Le code est un peu sans dessus dessous après la bataille, je le mettrai sur la dropbox dès que ce sera terminé et fonctionnel.

[atanorr]

Est-ce que tu veux dire que ton nouveau " binTodsf" peux avoir un impact sur les perfs notemment sur celles à 3 500 000 triangles? ou c'est juste à la construction de la tuile?

Pour les tuiles , sans zones montagneuses , je reste vers 2 000 000 triangles,
pour les montagnes , etc , je ne dépasse pas 3.500 000 triangles .

[Oscar Pilote]

Est-ce que tu veux dire que ton nouveau " binTodsf" peux avoir un impact sur les perfs notemment sur celles à 3 500 000 triangles? ou c'est juste à la construction de la tuile?

Disons que cela a un impact au moins sur les tuiles avec plus de triangles, puisque on ne peut pas les faire sans...
Ensuite à nombre de triangles égaux je n'en ai pas la moindre idée, dans la norme des fichiers dsf il est écrit :

Commands consist of a command ID and additional information in series. Command order is arbitrary but may be optimized for file size by the file writer. Command order does not affect display order when X-Plane renders scenery; display order is affected by internal factors in the rendering engine.

ce qui suggère qu'il n'y aurait pas ou peu de différence, mais je suis suspicieux sur ce point (il y aussi la décomposition en pools et en patch
dont il ne dit mot), il faudrait que PhM passe son "profiler".

Je referai des essais en montant encore afin de voir à quel moment les performances commencent à s'en ressentir (pour le moment
les temps/frame sont identiques avec Global Scenery ou avec 6.7 millions de triangles...) je suis de plus en plus persuadé que les
objets 3D (et les nuages) sont les seuls mangeurs de performance.

[atanorr]

je suis de plus en plus persuadé que les
objets 3D (et les nuages) sont les seuls mangeurs de performance.

il y a aussi le zoom 18, coûte 3-5 fps de plus qu'un zoom 16

Perso , je réalise toutes mes tuiles en z17 , c'est vraiment un bon compromis en 4k