Ortho4XP

[Dobro]

non...

mais il me semble que ça passait comme ça avec la version precedente

je suis en train de retester .. pour voir

[Dobro]

non clairement , il y a un truc qui devrai etre libéré, et qui ne l'est pas !

lors de la conversion en DDS , la charge memoire augmente constament sans jamais redescendre !
a mon avis , c'est pas normal !

je vais refaire le teste avec la version precedente, pour voir si c'etait deja le cas ...

[Oscar Pilote]

bon c'est vrais que j'ai beaucoup de triangles mais quand meme

mes paramètres pour cette tuile

curvature_tol = 0.2

Bon sang ce n'est quand même pas compliqué à comprendre :

tuile "plate" : curvature_tol peut être abaissé (0.2 est pas mal)
tuile "montagneuse" : curvature_tol trop bas engendre trop de triangles (3 ou 4, voir un peu plus ou un peu moins selon le matos)
et bien sûr ce n'est pas blanc/noir, il y a des tuiles "semi-montagneuses".

Pour rappel :

Global scenery : environ 500.000 triangles
HDv3 : environ 3 millions de triangles
UHDv1 : environ 6 millions de triangles

DobroMesh: 21 millions de triangles.
-> pas la peine de jouer aux apprentis sorciers à la recherche de fuites mémoires

lors de la conversion en DDS , la charge memoire augmente constament sans jamais redescendre !
a mon avis , c'est pas normal !

Cela n'a rien à voir avec la conversion des DDS. Pour gagner en rapidité, je sépare les trois tâches
que sont 1) le téléchargement des jpegs 2) leur conversion en DDS et 3) le remplissage des couches
de l'objet DSF en threads séparés (si tu as un multi-coeur tu dois voir qu'ils sont bien occupés).
Les tâches 1 et 2 ne requièrent quasiment pas de RAM, c'est la tâche 3 qui en nécessite car
Je lis les triangles les uns après les autres et les place dans la bonne couche à la volée, ce qui
impose de conserver pendant toute l'étape toutes les couches en mémoire. Il y aurait moyen de
d'améliorer cela mais au prix de jeux de pistes assez casse-tête (i.e. rendre le processus en
entrée/sortie/entrée/sortie etc plutôt que entrée/entrée/..../sortie/sortie/sortie); comme pour un mesh
raisonnable (même UHD) la consommation de RAM ne dépasse par 4Gb je n'ai pas jugé utile
de faire l'effort. L'option sniff (que j'ai introduite à contre coeur car je conçois le maillage et les
objets comme deux choses qui devraient être dans des dsf séparés), si le dsf que vous sniffez
a beaucoup d'objet, ajoute aussi en besoin de RAM (comme quand X-Plane charge un tel DSF...).

Got dimension properties, establishing file writer...
terminate called after throwing an instance of 'std::bad_alloc'
what(): std::bad_alloc

Là c'est c'est Ben Supnik qui veut faire une instantiation en C++ dans DSFTool, lequel rend l'âme par manque
de RAM (pourtant à ce moment Python a déjà tout rendu à l'OS... comme quoi Python n'est pas forcément
pire qu'un langage compilé, même en ce qui concerne la gestion mémoire ;-)

[Dobro]

DobroMesh: 21 millions de triangles.
-> pas la peine de jouer aux apprentis sorciers à la recherche de fuites mémoires

ben quand meme , je sais bien que tu vas pas concurrencer Zbrush (qui est une reference quant au nombres de triangles traités) , mais lorsque je vois la Ram se faire bouffer de la sorte
j'ai de quoi m'inquieter ...

c'est la tâche 3 qui en nécessite car
Je lis les triangles les uns après les autres et les place dans la bonne couche à la volée, ce qui
impose de conserver pendant toute l'étape toutes les couches en mémoire. Il y aurait moyen de
d'améliorer cela mais au prix de jeux de pistes assez casse-tête (i.e. rendre le processus en
entrée/sortie/entrée/sortie etc plutôt que entrée/entrée/..../sortie/sortie/sortie);

ha bah, voila, tout s'explique ...
question , vu la vitesse d'ecriture des disques Dur, pourquoi tu ne bosses pas sur Disque
car au lieu de saturer la Ram , le boulot se ferai sur disque (fichier) et du coup on aurai un gros confort d'utilisation
et permettrait l'utilisation de l'ordi pendant une création de Tuile...

bon , je reconnais, que je me suis planté niveau paramètre de triangles ...
mais quoiqu'il en soit, la Ram se fait grignoter quand meme ... c'est juste ... comment dire ça ..... "pas tres propre" (sans vouloir t'offenser )


ps: je retente en ce moment, avec Curve =2 ça monte moins vite effectivement ...

apparamment se stabilise a 2,6 go ouf !

[jasum]

@Oscar

Dans LFKX.patch tu as ajouté un attribut "profile= atanh ", je pense qu'il s'agit d'un profilé pente régulière? sinon par défaut ce serait le profilé en "S" on a donc le choix pour l’édition de patch.

[Oscar Pilote]

@Oscar

Dans LFKX.patch tu as ajouter un attribut "profile= atanh ", je pense qu'il s'agit d'un profilé pente régulière? sinon par défaut ce serait le profilé en "S" donc on le choix pour l’édition de patch.

Oui atanh est le profil en S couché, c'est aussi celui par défaut si on ne met pas de tag (et pour cause c'est le seul que j'aie codé pour l'instant...).
As-tu fais LFHU ? Je comptais sinon faire un vidéo le concernant, il y a des points intéressant comme la délimitation de la falaise au-delà du bout de piste.
As tu des remarques sinon, le bombé est-il peut-être un peu trop prononcé ? (je l'aime bien alors j'ai peut-être exagéré, mais je pourrais ajouter un
paramètre de contrôle (en fait il existe déjà et s'appelle coeff, tu peux le changer vers la ligne 1290, vers 0 on tend vers un plan incliné, et vers l'infini
on tend vers une marche abrupte en milieu de piste)).

[jasum]

@Oscar

Merci, je vais tester avec diffèrents coeff.

[atanorr]

@ Dobro..
laisse bien la Ram là ou elle est, les magasins pleurent pour en vendre ! , 8 giga c'est trop peux 12 minimum voir 16 n'est plus un luxe,
En plus créer su swap sur un disque dur, que tout le monde n'a pas encore un ssd , non merci.

21 000 000 de triangles ... est-ce que tu arrives à avoir ta scène qui bouge à 24 im/s ? dans le jeux? à mon avis non... ou alors en 800x600 ... sans hdr.. enfin voilà c'est mon avis
Ne dépasse pas 6 000 000 c'est déjà très très lourd ! en 4k avec titan X et un oc bien bien haut ! c'est encore lourd donc t'imagine ok, tu n'es pas en 4k , mais à l'heure ou les écrans de tv pour moi deviennent meilleur que les écrans de pc ( pour les jeux uniquement ) en résolution full 4k , écran incurvé 1,2m de diagonale , pas besoin de 3 pc pour faire tourner xplane , pas besoin de 3 écrans qui te déforme l'image, pas beoin de plug in pour reconstruire l'image sans effet œil de poisson , tout fonctionne dans le cockpit car avec 3 pc différents ( c'est la m e r d e ) ! bref, je m'emporte dans ce qui me semble le meilleur pour x plane , après 5 ans dessus ou 4ans je sais plus .

Si tu aimes la simu, pourquoi ne t'équipe tu pas de ce qu'il faut pour savourer des graphismes à la hauteur de ce que Oscar et d autres réalise pour le jeux?
Xplane sur un écran de "gsm" je préfère largement inverstir dans une tour: un pc, un Excellent écran ! pas celui qui coute 50€ que tu vas regretté dans 2 semaines ! et pas un portable que l'on ne peut absolument pas upgrader .

[atanorr]

@OSCAR

OSCAR ne rigole pas hein ... j'essaie de comprendre quelques ligne de code en python ^^

#!/usr/bin/env python3                                                       
from wand.image import Image

with Image(filename='*.pnm') as img:
    img.format = 'png'
    img.save(filename='*.png')

j'essaie de trouver pour image magick pour la conversion ^^ j'ai encore du boulo ^^
j'ai pas le module named wand ,
(je pensais que ça fait partie de imagemagick ^^ )

Ni rigole pas j'ai dit :D

Me faut trouver avec convert :D

[Oscar Pilote]

@Atanorr
Pas besoin de python, les lignes que je t'ai indiquées sont à lancer dans une fenêtre de commande, tu
tapes juste
convert assemblage_bidule_chose.pnm belleimagedatanorr.jpg [enter]
puis quand tu as fini d'éditer
convert belleimagedatanorr.jpg assemblage_bidule_chose.pnm

(tu peux remplacer jpg par n'importe qu'elle extension que convert et Photoshop connaisse tous les deux,
je te conseille de laisser un format non compressé le plus simple possible, pas la peine de perdre son
temps en un aller/retour de compression)

[atanorr]

@Atanorr
Pas besoin de python, les lignes que je t'ai indiquées sont à lancer dans une fenêtre de commande, tu
tapes juste
convert assemblage_bidule_chose.pnm belleimagedatanorr.jpg [enter]
puis quand tu as fini d'éditer
convert belleimagedatanorr.jpg assemblage_bidule_chose.pnm

(tu peux remplacer jpg par n'importe qu'elle extension que convert et Photoshop connaisse tous les deux,
je te conseille de laisser un format non compressé le plus simple possible, pas la peine de perdre son
temps en un aller/retour de compression)

.png
Grand merci , ça fonctionne ,

[jasum]

@Oscar

Je ne me suis pas encore occupé LFHU.

J'ai testé plusieurs coeff*:

effectivement coeff=3 semble un peu fort sur LFLJ vu la pente moyenne de #20%

sur LHM et LFKX je trouve cela pas mal.

Avec coeff=2, LFLJ me paraît plus réaliste mais adieu le magnifique raccord avec l'apron que tu avais peaufiné*!!!

sur les 2 autres c'est bon.

[Oscar Pilote]

Voilà je viens de faire LFHU en direct ici.

En début de vidéo je montre l'état de la piste LFHU (Alpe d'Huez)
avec Ortho4XP sans patch de terrain. Comme les frontières de LFHU
sont encodées dans Openstreetmap, Ortho4XP opère par défaut un
nivellement semblable à l'option "runway follow terrain" décochée de X-Plane.
On voit bien les défauts que cela engendre en montagne, en plus de la piste
monotone (parking et terrains de tennis à moitié dans la pente de la falaise,
etc).
Dans un deuxième temps, je montre comment créer un fichier
de patch à l'aide de JOSM [c'est on ne peut plus simple, mais au préalable
il faut se munir d'une carte et/ou des outils nécessaires à l'obtention des
altitudes que l'on souhaite forcer dans le maillage - les données de
l'exemple ont été rentrées à l'aide de la carte VAC de l'aéroport pour la piste,
et un peu au pif pour le reste].
Une fois le patch réalisé je relance Ortho4XP sur la tuile (une première fois pour
des prunes puisque j'avais oublié d'effacer les fichiers temporaires précédents...),
et je montre ensuite le résultat dans X-Plane.
Notez que la piste X-Plane est décalée par rapport à la piste réelle,
ce qui fait qu'au départ croyant être en milieu de piste je suis en réalité sur le bord droit,
et cela secoue un peu. Il faudra(it) modifier le fichier apt.dat de la scène LFHU.

[Oscar Pilote]

Avec coeff=2, LFLJ me paraît plus réaliste mais adieu le magnifique raccord avec l'apron que tu avais peaufiné*!!!

Avec 3 le bombé est plus prononcé mais la pente aux extrémités est faible, ce qui fait un bon raccord avec
l'apron qui est plat.
A l'extême avec 0, tu as une piste en plan incliné droit et l'ange entre ce plan incliné et l'apron plat engendra
nécessairement un sursaut.
Une piste à explorer serait de décentrer l'atanh pour que son axe de symétrie soit plus proche du bas de
piste que du haut de piste (c'est d'ailleurs un peu ce qu'on observe quand on examine les altiports réels).
La pente d'attaque de la piste à l'aterrissage serait plus prononcée (pas forcément gênant) et la pente
haute plus proche de l'horizontale, pour une meilleure transition.
Tu peux t'amuser à le faire seul si tu veux, prend d'abord du papier et un crayon pour ne pas planter
les formules ;-)

Je vais essayer de tester ce que donne un patch sur un aéroport plat, en mettant à plat la piste, les taxiways et les apron,
et en laissant le relief pointer le bout de son nez là où de toute façon on ne roule pas. Ca donnera peut-être
un petit plus, ou un petit moins, à voir...

[Odevillée]

Notez que la piste X-Plane est décalée par rapport à la piste réelle,
Il faudra(it) modifier le fichier apt.dat de la scène

Y en a plein dans Xplane, des pistes décalées.