Ortho4XP

[PhM]

...Dans un message précédent j'avais comme toi mentionné le fait que les maillages de base de Laminar et/ou HD de Alpilotx sont pensés pour des textures basées sur les landclass, pas pour les orthophotos, et de ce fait ils contiennent beaucoup plus de triangles que nécessaire dans ce dernier cas ...

Lanclass, ça fait très FSX . Le nombre de triangles ne doit dépendre que de la courbure du terrain à un endroit donné et en aucun cas de la texture qui sera appliquée sur les triangles. Si c'est plat on peut se permettre de grand triangles, sinon il en faut beaucoup de petits. Chaque point des triangles contient également une normale qui sert à déterminer comment le triangle réfléchira, modifiera etc la lumière qui lui arrive, soleil ou autre, et donc si le nombre de triangles ne suit pas d'assez près la courbe du terrain l'éclairage apparaitra comme bizarre.

Leur mesh est fait dans cette optique. Ensuite la façon dont ils l'utilisent avec leur rendu de terrain non ortho-photos est loin d'être efficace puisqu'ils arrivent à souvent ne tracer que quelques triangles, ça va jusqu'à moins de dix, avec un texturage donné. Résultat on perd son temps dans openGL et le GPU se tourne les pouces.

...un maillage HDv3 contient entre 2 et 3 millions de triangles par tuile...

Le gros problème avec ce mesh, comme avec celui d'origine mais dans une moindre proportion puisque comportant moins de polygones, est que c'est un mesh fixe. Il y a toujours le même nombre de polygones quand bien même au loin on n'a pas besoin de tracer tout ça. Pour avoir du rendu de terrain performant il faut travailler avec des niveaux de détail qui déterminent le niveau de tessellation à un endroit donné. Comme ce n'est pas disponible dans X-Plane ce mesh permet une plus grande finesse au détriment du gaspillage de resources, et donc tant pis pour ceux avec des petites configurations vous avez toujours vos yeux pour pleurer.

...l'eau est un landclass que l'on veut conserver, il faudra donc que le maillage soit tel que tous ses triangles sont soit
entièrement en eau soit entièrement en sol, ...

Dans les termes utilisés en moteur graphique l'eau est un matériau qui sera appliqué sur un ensemble de polygones. C'est plus qu'une simple texture puisqu'il ne faut pas oublier les différents shaders utilisés ainsi que les autres variables d'état openGL à utiliser pour ce rendu. Pour des raisons d'efficacité il est impératif de garder tous les polygones avec un matériau donné, l'eau par exemple, ensembles afin d'éviter de trop nombreux changements d'état dans openGL. Moins on change l'état plus vite on va, poil aux doigts.

... 2) on veut mettre plus de triangles là où il y en a besoin, c'est-à-dire là où le relief est chaotique, et moins en plat pays. ...

C'est ce qui est déjà fait dans la version d'origine, voir première réponse, je crois me souvenir qu'il y avait un article là dessus mais je ne le retrouve pas.

De mon côté mon projet MeshEdit à fini par dériver en expérimentation sur comment tracer ce mesh de la façon la plus efficace, qui s'est transformée en un autre projet XPGRRP (X-Plane Graphis Renderer Replacement Project) qui fait son chemin, lentement .

PhM

[Daniel_L]

...
C'est ce qui est déjà fait dans la version d'origine, voir première réponse, je crois me souvenir qu'il y avait un article là dessus mais je ne le retrouve pas.
...

C'est ça ?

http://developer.x-plane.com/2009/04/so-how-big-of-a-mesh-can-you-build/

Daniel

[Oscar Pilote]

@ PhM et Daniel_L
Je n'ai pas dis que meshtool jouait aux mots-croisés, bien au contraire, mais que
j'avais à ma disposition des outils (qui ne sont pas de mon fait mais open source)
qui sont (un peu) meilleurs pour simplifier un maillage 3D (en fait meshtool fait l'inverse, il le
complexifie en partant d'un simple, d'autres approches plus classiques partent d'un
maillage fin et le simplifient).
J'ai pris contact avec B. Supnik il y a deux ou trois mois, et nous avons fait quelques
essais comparatifs ensemble. Comme ils n'ont par ailleurs pas l'intention de prendre le
chemin des orthophotos (c'est assez compréhensible), et qu'il est submergé par bien
d'autres choses plus pressantes, je vais continuer mon petit bout de chemin tout seul (enfin
avec vous!).

PhM : Le nombre de triangles ne doit dépendre que de la courbure du terrain à un endroit donné et en aucun cas de la texture qui sera appliquée sur les triangles.

Tu as parfaitement raison et je partage entièrement ce point de vue.
Par contre quand tu écris :

PhM : Leur mesh est fait dans cette optique.

là non pas du tout, c'est l'exemple que j'ai donné plus haut dans le fil avec l'histoire du champ
et du verger : les frontières des landclass (cette dénomination est antérieure à l'existence
même de microsoft) sont forcées comme des arêtes requises du maillage. Si vous lisez l'allemand
A. Fabian en a fait un article ici

http://www.simflight.de/2014/08/15/mesh-und-landclass-der-x-plane-welt/

Je vais arrêter sur le maillage ici (j'ai dit un lièvre à la fois!), lebelge m'a signalé que j'ai introduit
un bug ce matin qui engendre une erreur de segmentation...

[Oscar Pilote]

Le gros problème avec ce mesh, comme avec celui d'origine mais dans une moindre proportion puisque comportant moins de polygones, est que c'est un mesh fixe. Il y a toujours le même nombre de polygones quand bien même au loin on n'a pas besoin de tracer tout ça. Pour avoir du rendu de terrain performant il faut travailler avec des niveaux de détail qui déterminent le niveau de tessellation à un endroit donné. Comme ce n'est pas disponible dans X-Plane ce mesh permet une plus grande finesse au détriment du gaspillage de resources, et donc tant pis pour ceux avec des petites configurations vous avez toujours vos yeux pour pleurer.

(...)
2. In the long term, we expect most of our mesh's quality to come from hardware tessellation on the GPU, and for the triangle budget to go down significantly...in this situation, the error metric will be relatively unimportant because so much of the 'mesh quality' will come from dynamic tessellation and not static triangulation.

(This isn't coming that soon, but we have to answer the question of scalability, which our static meshing system is not. My general feeling is that scalability will come from the GPU, and having meshes with the 'weight' of the UHD meshes - which seriously lower X-Plane's performance - won't be necessary.)

cheers
Ben

Ils en sont bien conscients mais tu peux prendre ton temps pour XPGRRP ils ne sont pas prêts de te doubler ;-)
J'ai pris le parti de me contenter de l'existant et de faire au mieux (ou au moins pire) avec...

[PhM]

C'est ça ? ...

Non, je me souviens de quelque chose qui montre comment un terrain plat (dans n'importe quelle direction) est constitué de moins de triangles qu'un terrain à l'orientation changeante. Ce n'est peut-être pas un article sur X-Plane mais une présentation GDC ou SIGGRAPH.

PhM

[PhM]

...là non pas du tout, c'est l'exemple que j'ai donné plus haut dans le fil avec l'histoire du champ
et du verger : les frontières des landclass (cette dénomination est antérieure à l'existence
même de microsoft) sont forcées comme des arêtes requises du maillage. ...

Voilà ce dont je parle :



On voit bien que les triangles sont plus larges la où le terrain est plat.

PhM

[Oscar Pilote]

On voit bien que les triangles sont plus larges la où le terrain est plat.

Oui heureusement, et je n'ai jamais remis cela en cause (à l'occasion je pourrai expliquer précisément
comment fonctionne meshtool sur le forum, ce n'est pas très compliqué du point de vue algorithmique).
Ce que j'ai dit être inexact c'est "en aucun cas de la texture qui sera appliquée sur les triangles".
Malheureusement ce dernier point engendre une différence importante dans la quantité et le rapport
d'aspect final des triangles.

J'ai fait une petite vidéo (qui vaut mieux qu'un long discours ;-) de ce qui me semble être un maillage (un peu)
meilleur que ceux obtenus par meshtool : www.youtube.com/watch?v=2ffyDKqFf8g
(malheureusement youtube en fait de la bouillie en mp4, mais cela reste probant je crois si on met en hd et en plein écran)
Ce maillage possède une densité locale de triangles qui est proportionnelle uniquement à la courbure locale,
et comme on le voit aussi l'énorme majorité des triangles sont au plus proche de l'équilatéral (les abeilles, en les regroupant
par six en hexagones, nous ont appris que c'était une solution optimale à bien des égards).

A bientôt

[PhM]

... Ce que j'ai dit être inexact c'est "en aucun cas de la texture qui sera appliquée sur les triangles". ...

Je ne comprend plus, ici tu es d'accord que ça ne doit pas dépendre de la texture, et maintenant tu dis le contraire.

PhM

[Oscar Pilote]

Je ne comprend plus, ici tu es d'accord que ça ne doit pas dépendre de la texture, et maintenant tu dis le contraire.

Je résume :
tu dis "il faut (i.e. dans l'absolu) la densité proportionnelle à la courbure et ne tenant pas compte des textures"
je dis "parfaitement d'accord"
tu dis "leur mesh est fait dans cette optique"
je dis "pas d'accord concernant la deuxième affirmation sur les textures"
Il est tard de ce côté-ci de l'atlantique, pardon de ne pas avoir été plus clair.

PS) M'a l'air bien foutu ce MeshEdit, pourquoi l'avoir mis de côté ? Je suis sûr que beaucoup d'utilisateurs,
moi le premier, seraient ravis de pouvoir s'en servir.

[PhM]

...
tu dis "leur mesh est fait dans cette optique"
je dis "pas d'accord concernant la deuxième affirmation sur les textures"
...

Ok, donc tu penses que leur mesh est fait en fonction des textures qui vont y être appliquées ? Ce n'est pas ce que j'ai constaté.

PhM

[Oscar Pilote]

Oui, c'est un peu plus qu'une supposition, le fichier source qui est au coeur de meshtool est celui-ci :

http://dev.x-plane.com/cgit/cgit.cgi/xptools.git/tree/src/XESCore/MeshAlgs.cpp

il est assez bien documenté mais on peut aussi se reporter au manuel en ligne :

MESH_SPECS <point count> <error>
This command controls the density and quality of the mesh that is generated. MeshTool builds your mesh using the following steps:

1) Points are added to form the basic mesh structure, match any adjacent already made meshes at the edges, and represent any polygonal features exactly. This step can add as many vertices as is necessary to meet these goals. A rough grid is placed in open water.

2) Points are added in priority order from the DEM to reduce the vertical error between the partly built mesh and the original DEM. The points are added on a worst-case-first basis…that is, the point that is most wrong in our mesh compared to our DEM is added first.

This process repeats until one of two conditions takes place: - We have added <point count> new points or - The worst error between the DEM and our mesh is less than <error>

3) Additional points are added to assure that no triangle is larger than 3.5 km on a side.

The MESH_SPECS command lets you tune your mesh by adjusting the “point budget” and error limit. You can think of these two numbers as “stop” conditions:

<point count> guarantees that we won’t just add points forever. When terrain is very complex, point count stops us from adding all 1.5 million+ DEM points into the mesh and producing an unflyably slow mesh.

<error> stops us from adding points when we reach a point where adding new points isn’t doing us any good. For example, if we set our error limit to 1 meter and our point count to a huge number (1 billion points, for example) then MeshTool will keep adding points until the worst error in the entire mesh (compared to the original DME) is only 1 meter.

Au passage, le chiffre de 3.5km au point 3) n'est pas à jour, la version git dont j'ai mis le lien ci-dessus est à 1.5km (et 6km pour la version iphone), cela se trouve ligne 140. Dans les deux cas cela explique entre autre pourquoi Ortho4XP doit parfois réduire le zoomlevel cible de certains triangles quand ils ne rentrent pas dans le chevauchement (qui fait +- 800m en ZL16 et 400 en ZL17). Les utilisateurs aventuriers pourraient modifer la ligne 140 pour se concocter leur propre maillage en attendant d'autres solutions (mais ils devront être à même de fournir les shapefiles, cela suppose une certaine familiarité avec l'outil..).

Le fonctionnement de l'algorithme de meshtool est aussi expliqué de manière un peu moins abrupte dans l'article d'A. Fabian que j'ai indiqué quelques posts plus haut, en le passant dans translate.google cela se lit très bien. Pour créer les hd sceneries, Andras lance meshtool avec un budget triangle plus élevé que celui des dsf du global scenery, et il utilise aussi des shapefiles plus détaillés en input, après les avoir extraits de bases GIS publiques (dont openstreetmap mais pas uniquement).

[PhM]

Oui, c'est un peu plus qu'une supposition, le fichier source qui est au coeur de meshtool est celui-ci :...

Ce que je constate vient des DSFs eux-même, comme le montre l'image que j'ai mis en lien précédemment plus c'est plat plus la surface des triangles est grande. Donc je comprend que meshtool ne fonctionne pas comme ce qui a été utilisé pour générer les DSFs.

Au vu de l'extrait que tu cites les choses ne semblent pas très claire, je vais lire ça plus en détail.

PhM

[Odevillée]

Wouaww ... trop fort le mec !!!





Bon...
Revenons aux choses sérieuses.

Je viens de faire quelques tests sur la Belgique (avec Ortho4XP)
Premières remarques :

1.- C'est très rapide (bien plus rapide que G2XPL)
2.- C'est puissant (car on peut (enfin) définir différentes zones d'une même tuile en plusieurs niveaux de zoom)

L'intérêt, c'est que :

- Lorsque vous survolez des champs (à haute altitude) , pas besoin d'une haute définition (zoom 14, c'est bon).
- Lorsque vous approchez d'une ville (moyenne altitude), une meilleure résolution est nécessaire (zoom 16, c'est bon).
- Lorsque vous approchez d'une piste atterrissage (basse altitude), vous avez besoin d'une haute définition (zoom 18, c'est parfait)

Et tout cela, finalement, occupe moins de place sur le disque... et donc forcément, c'est chargé plus rapidement et cela occupe moins de place au niveau de la CG.

Reste les bords de mer mais Oscar Pilote est plein d'idées. Je suis certain qu'il y arrivera.
Faut juste qu'il se préserve un peu (on a aussi une vie privé)... sinon, on pète un câble (comme cela m'arrive parfois... souvent ? à bon !!!).

lebelge

@ Bertrand : J'ai bien compris ton message. Je n'interviendrai plus aux remarques qui n'ont rien à voir avec ce topic (effectivement) très intéressant.

Tout à fait d'accord avec Lebelge.
Première tuile d'essai réussie zone d'ostende en z17 pour voir l'effet de l'eau, magnifique programme que nous fait oscar pilote, meilleur visuel qu'avec G2xpl.
A suivre.

[Oscar Pilote]

Bonsoir,

J'ai uploadé dans le répertoire Experimental un fichier nommé Water_overlay_g2xpl.py. Il s'agit du petit utilitaire que je vous avais promis et qui permet d'ajouter un effet de transparence et les reflets de l'eau aux tuiles qui ont été réalisées avec g2xpl (celles pour laquelle l'option 'eau à la X-Plane' a été retenue, telles celles de zonephoto). Le rendu de l'eau après post-traitement est alors assez semblable à celui d'Ortho4XP, mais avec un maillage de nature différente.

Si vous ne souhaitez pas refaire votre toit avec Ortho4XP, ou que son fonctionnement vous paraît trop complexe, cela peut être une solution à essayer pour certaines tuiles. Cela n'engendre aucun téléchargement d'image supplémentaire et le fichier dsf original est sauvegardé en .bak à côté du nouveau dsf, ce qui permet de faire machine arrière de la plus simple des manières. Générer le nouveau dsf à partir de l'ancien ne prend que quelques secondes (cfr aussi ci-dessous pour une méthode encore plus élémentaire en exemple).

Une mise en garde sur le rendu : le travail a été un peu moins direct que je ne l'imaginais, car j'ai découvert que dans les tuiles réalisées par g2xpl avec l'option eau d'X-Plane les triangles d'eau ne subissent pas l'algorithme de découpage de Robert2 (il n'y en a pas besoin puisque justement ils sont laissés en eau et ne prennent pas de texture ortho). Du coup, pour ajouter les orthos sur l'eau en utilisant ses textures j'ai du réimplémenter moi aussi son algorithme de découpe, et même si cela fonctionne c'est loin d'être parfait de mon côté (et je n'ai pas une motivation folle à bosser sur cette partie... par ailleurs j'ai vu que Robert2 le mettait sur la liste des choses qu'il pensait ajouter). Si certains ont envie de le tenter eux-mêmes, je peux expliquer ce qu'il conviendrait de faire pour éliminer les artefacts restants. Dans la situation actuelle, en gros pour du ZL16 et des tuiles sans bord de mer cela se passe pas trop mal, par contre en ZL17 sur le lac Léman ou situations analogues vous risquez fort de voir apparaître des 'oops' ou des 'texture missing' de la part de Water_overlay_g2xpl. Rien de grave (tout est réversible 'en un clic') mais probablement que si ces messages apparaissent votre nouveau dsf aura certains triangles très peu esthétiques.

Pour ceux qui veulent essayer sans passer par git, python et tout ce qui s'en suit, je viens d'uploader sur le forum (rubrique Downloads/Scènes) une tuile que l'on obtient en lançant le script (avec ratio_water=0.2) sur celle correspondante de zonephoto. Pour des raisons de taille je n'ai pas intégré les dds à l'upload (qui fait 13Mb), il vous suffit de recopier ceux de la tuile zonephoto. Un décollage depuis LFLB et c'est parti pour les abords du lac du Bourget, le Revard, la dent du chat,
le Rhônes et le canal de Savière [attention si vous avez la scène de l'aéroport LFLB de XPFR elle ajoute elle même quelques orthos en overlay, virez-la le temps du test (puis remettez là car elle est splendide ;-)].

Bon vol !

[Oscar Pilote]

pour ma part, ce qui me bloque le plus a propos d'X-plane (coder la meme chose que Otho4XP par exemple )
ce n'est pas la programmation , c'est l'information , pour coder un truc, il faut le connaitre
et on peut pas dire que l'info soit exhaustive a propos d'X-plane ...
de plus tout en Anglais .... faire des recherches prends un temps fou

Tu mets le doigt sur un point clé !

En plus de l'excellent wiki http://wiki.x-plane.fr du forum, il y a http://wiki.x-plane.com et http://developer.x-plane.com
que tu connais sans doute déjà, mais qui effectivement sont en anglais (et pas toujours à jour). On s'en sort quand même
et l'essentiel de l'information s'y trouve. Il y a aussi plusieurs personnes qui ont réalisé des tutoriels, certains comme ceux
de Milan sont je crois très complets.

Au-delà d'X-Plane, pour ce qui est des tuiles orthos, et par exemple de leurs différents modes de numérotation, une source très
simple mais très bien faite est https://msdn.microsoft.com/en-us/library/bb259689.aspx (comme quoi micromou n'est pas
capable que du pire ).
On peut jouer aussi avec l'applet http://www.maptiler.org/google-maps-...ds-projection/ pour se persuader qu'on a compris !
Pour les sites d'images qui ne se basent pas sur ce découpage à la Bing/Google (par exemple Walonmap et Minambiente),
j'ai du passer par des changements de coordonnées un peu plus ardus, alors je me suis reposé sur un vieux mais très bon
livre pour les férus de cartographie : http://pubs.er.usgs.gov/publication/pp1395 (j'ai indiqué les pages des formules dans le
fichier source).


Bonne lecture (pas en volant !)