[P3D][FSX] En route vers la scène photo-réaliste parfaite ?

MINOSI · [↑]

Personnellement, je considère que sur une scène les bâtiments c'est une chose, et qu'il est agréable qu'ils soient bien modélisés, mais que ce que au sol on voit essentiellement derrière ses cadrans, ce sont les surfaces de service et les runways. Mais les malheureuses pistes microsoft font piètre figure.

L'alternative, c'est la texture sol photoréaliste... à condition qu'elle couvre également ces surfaces "grises".

Et là, deux techniques d'affichages des textures photoréalistes sont possibles:

- des "ground polys", déclarés dans un bgl spécifique qui ne comportent que leur positionnement et charge des "tuiles" présentes dans le dossier "TEXTURE" de la scène. Ces polygones se chargent AU DESSUS de l'afcad et présentent l'avantage essentiel de cacher les textures génériques des pistes pour afficher la "photo" des pistes réelles. Et à ce stade deux options pour les marquages sont possibles, avec chacune des avantages/inconvénients trop long à exposer ici :
- soit les marquages de la photo réal elle-même
- soit des "ground polys" spécifiques à ces marquages, qui s'afficheront sur un layer (une couche) lui-même encore au-dessus de la photo-sol. Laquelle devra de préférence dans ce cas avoir d'abord été débarrassée par retouche photoshop (ou autre!) des dits marquages.
Mais oublions cette option là, qui est secondaire par rapport au choix plus important à faire entre les deux techniques d'affichage des sols photos.

La seconde possibilité est celle-ci :
- une image sous format bgl, (dans ce cas, le bgl "contient" la texture"), laquelle se plaquera directement sur le mesh de la scène avec beaucoup d'avantages : pas de scintillement, pas de masquage des effets sols tels que "vasi papi" et autres feux de pistes, la possibilité de saisonnaliser le sol. Et, à texture de départ identique, un meilleur piqué de l'image, moins de problème de raccord entre les "tuiles" composant l'image (voire aucun raccord, mais ceci implique alors un poids doublé du fichier "bgl" pour les scènes détourées puisqu'il doit contenir un masque alpha de la totalité de l'image... ce qui serait en fait le cas de toutes les scènes si on ne veut pas avoir une texture-sol "au carré". Le détourage est encore plus obligatoire dans les scène incluant une surface en eau).

J'ai longtemps buté sur le fait que les aprons, taxis et runways, qu'ils soient génériques ou d'origine "ADE", se positionnent AU DESSUS du mesh et de sa texture. Puisque le but ultime de tout ça est bien de les éliminer tellement les pistes microsoft sont laides. Non ?
Mais finalement quelques astuces permettent de totalement "virtualiser" ces surfaces sans qui ni l'ATC ni le trafic AI n'y voient le moindre inconvénient ! A PARTIR DE CE MOMENT, IL EST POSSIBLE DE DISPOSER D'UNE IMAGE PHOTO-REALISTE (par exemple !) SUR LA TOTALITE D'UNE PLATE FORME ET DE PLAQUER CETTE IMAGE SUR LE MESH (et non plus au-dessus des surfaces de service/runway).

Que des avantages à priori... mais malheureusement un inconvénient dont je ne comprends pas l'origine. Sans ce problème, la question du choix entre les deux solutions ne se poserait pas... et ce post aurait été un "tuto".

Alors voyons sur photo.
Sur la première, les deux solutions sont juxtaposées :
- à droite de l'image, un "ground poly" défini dans ADE et exporté sous forme d'un "bgl" spécifique. Ce polygone "flotte" à un pouième au dessus du mesh de la scène. Il masque tout ce qui se trouve en dessous, les "effets" éventuels, et les surfaces de service et/ou runways. Mais vous aurez noté que sur cette image "il n'y a rien à cacher" puisque l'afcad a été "virtualisé".
- à gauche, un second polygone de même taille (2048 x 2048 pixels) et même LOD mais "resamplé" par l'outil adéquat du SDK de FSX et qui se colle exactement sur le mesh.
(la discontinuité entre les deux tuiles est "normale"... je veux dire par là parfaitement explicable et facile à résoudre. Dans l'exemple, elle permet de visualiser la limite entre chacune des deux tuiles)

[img align=c]http://i57.servimg.com/u/f57/11/73/62/86/2_bmp10.jpg[/img]

=> constatation : dans cette capture, la qualité visuelle est strictement identique entre les deux techniques

Mais il n'en va pas de même "au sol" !
Au crédit de la seconde technique : "l'image bgl", représentée à l'avant plan sur l'image ci dessous, montre que l'affichage est nettement plus piqué.

[img align=c]http://i57.servimg.com/u/f57/11/73/62/86/3_bmp10.jpg[/img]

Mais c'est sur une vision distante que le bilan se dégrade gravement. Cette prise est faite sur la tuile gauche et montre un fort floutage devant le nez de l'appareil.

[img align=c]http://i57.servimg.com/u/f57/11/73/62/86/4_bmp10.jpg[/img]

alors que sur cette autre vue, faite devant le nez de l'appareil posé cette fois sur la tuile droite, on voit qu'une texture affichée par "ground poly"ne présente pas de floutage. Mais, à la jonction des deux tuiles, Il ré-apparaît nettement sur la texture affichée par "image.bgl".

[img align=c]http://i57.servimg.com/u/f57/11/73/62/86/5_bmp10.jpg[/img]

Et là je ne vois pas vraiment d'explication au phénomène. Les suggestions seront les bienvenues !
Car dans l'état le problème est suffisamment dissuasif pour éliminer cette pourtant belle solution. Ah... à signaler un inconvénient qu'elle présentera obligatoirement : la nécessité de pousser à droite le curseur du réglage de qualité des décors -15cm en l'occurrence - ce qui engendre des désagréments d'affichage sur d'autres décors à la résolution moindre.
A l'inverse, une texture placée sur un ground-poly s'affichera proprement quelque soit la résolution de la texture des décors.

Mais dans tous les cas et quelque soit la solution retenue rien de tel qu'un sol réaliste à COUVERTURE INTEGRALE non ?

[img align=c]http://i57.servimg.com/u/f57/11/73/62/86/6_bmp10.jpg[/img]

Malheureusement il faut être clair : un tel résultat n'est pas distribuable puisque les images d'origine ne le sont pas ! (à l'exception peut-être de openstreetmap mais avec à ce jour une qualité bien inférieure).
En revanche, ce qui est distribuable c'est toute la méthode pour passer des tuiles "capturées" par chacun à la scène affichée sur son écran perso.

Et ce qui est également distribuable c'est le (très gros) travail de retouche des photos satellites en vue de les débarrasser des avions, voitures et autres arbres indésirables écrasés au sol. Et redessiner proprement les marquages sol (ou les recréer sous forme de polygones dédiés puisque l'option est ouverte dans les deux cas).
Alors... avis aux amateurs sur "ma plate-forme de résidence" et origine des captures ci-dessus : LFMT !

Mais dans l'immédiat, ce qui m'intéresse avant tout ce sont toutes les suggestions qui pourraient amener à résoudre ce dernier problème d'affichage des "images.bgl" hélas rédhibitoire en l'état.

Merci par avance !
Une "auto-suggestion" toutefois, pour avis. Ce problème de floutage, je l'ai en fait également observé sur des ground-polys, lorsque le bmp (ou dds) qu'ils affichent comportent des mipmaps. Mais pas avec une telle ampleur.
Et à ma connaissance, l'outil "resample" du SDK, qui fabrique le bgl image, ne le dote pas au passage de mipmaps ?

Dernière modification par MINOSI (09-05-2014 05:40:24)

Thierry DeBrest · [↑]

hello !

Pour moi une scène photoréaliste parfaite c'est une utopie.
Je ne suis que peux adepte du photoréalisme pour une seule et simple raison : Pas de gestion des saisons.
Ou est le réalisme dans le photoréalisme quand il n'y a pas de neige en hivers ou les couleurs de l’automne ?

je me demande si je suis pas hors sujet là ^^

PatDeBarr · [↑]

Bonjour à vous deux,

@ Thierry DeBrest :
Les textures sol saisonnières sont parfaitement réalisables ...
Voir ici : http://avalsace.free.fr/CREATION.htm mon tuto 'TexturesX Sol', j'explique dans le §8 comment réaliser les 6 saisons de FS-X : Printemps, Eté, Automne, Hiver, Hiver rude et Nuit !
Deux problèmes :
> Chaque texture prend beaucoup de temps à être traitée pour chaque saison,
> Cette action multiplie d'autant la taille du fichier contenant cette texture.

@ MINOSI :
Ton sujet est très intéressant ...

Le floutage des textures sol est effective un problème difficile à contourner :
> En texture sol construite par Resample, le meilleur rendu lisible par FS-X est en LOD19, soit 7cm/pxl, il faut donc déjà que FS-X soit réglé sur cette valeur.
> Mais on peut donc envisager une couverture du sol dans cette qualité. Le bitmap de base peut être construit entièrement à la main ou en partant éventuellement de ce qui existe en distribuable gratuitement et en le passant dans les griffes des logiciels de retouche pour en augmenter, au besoin, la résolution.
> Cette texture peut être nettoyée de tout marquage non souhaité.
> Les Blend Mask créeront simplement les joints nécessaires avec l'environnement.
> Les Water Mask délimiterons avec précision les zones liquides.
> On peut également penser à rendre cette texture saisonnière.

Le détail des marquages sol sera plus net s'il est réalisé directement sous la forme d'un objet texturé laissant apparaitre les tracés voulus à travers un bitmap transparent en DXT1 avec Alpha par exemple.
On peut alors maltraiter ces marquages au besoin : vieillir, salir, user ... suivant l'inspiration de l'artiste (voir ma librairie 'Marques').
Le revers sera le nombre d'objets placés et donc le nombre et la taille des textures HD associées.

Manolo vient de nous sortir un tuto très intéressant sur ces pistes traitées en HD ... à lire ici : http://www.pilote-virtuel.com/viewtopic.php?id=61950 !
Celui-ci utilise le SDK de FS2002, mais donne de bons résultats.

Voilà quelques lignes de réflexion ...

Patrick

Dernière modification par PatDeBarr (09-05-2014 14:00:31)

MINOSI · [↑]

Bonsoir Patrick,

merci pour ta longue réponse.
J'ai en raccourci bureau un doc de référence : textureX sol.pdf

Je suis donc conscient de réinventer largement le fil à couper le beurre. Mais il me semble aussi que j'apporte une nouveauté par rapport à tout ce que j'ai lu, ou observé sur les quelques scènes en ma possession : la possibilité de totalement squizer l'affichage de l'afcad, sans pour autant le rendre inopérant. Ceci ouvre alors le champ à une texture photo épousant le mesh ET affichant les pistes réelles.
Au défaut près du floutage en vue au sol, que tu confirmes hélas impossible à éviter.

J'ai bien sûr vu le tuto de Manolo. La préoccupation est la même que la mienne : s'affranchir des textures microsoft. Son approche étant une alternative puisque lui les recouvre alors que je les élimine.

J'aimerais une précision s'il te plaît concernant les blend mask dont je ne suis pas certain d'avoir compris la fonction.
Et dont je crains qu'ils ne demandent une "image (une source) "supplémentaire" avec une augmentation d'autant de la taille du bgl...
Pour ma part, je traite les raccords de la scène avec l'environnement exactement comme les détourages d'eau, en jouant sur le dégradé de gris, le tout donc en une seule texture "masque" créée au gros pinceau ( laquelle donne la couche alpha dans le cas d'un polygone texturé, la seconde source dans le cas d'un bgl resamplé). Pour l'instant, mon procédé me donne un résultat qui me convient mais aurais je un bénéfice à séparer la fonction blend mask de la fonction water mask ?

[img align=c]http://i57.servimg.com/u/f57/11/73/62/86/2014-511.jpg[/img]

Une précision qui pourra peut-être intéresser : ton tuto fait état de SBuilder pour obtenir les tuiles photo de départ. Filipo de son côté développe l'utilisation de FSET. Mais ni l'un ni l'autre ne m'ayant permis d'obtenir les images que je convoitais (pas su trouver les paramètres du "service" qui les aurait fournies) j'ai utilisé "Maps Downloader", un soft d'une mise en œuvre simplissime mais qui a juste le petit inconvénient d'être payant.

Philippe

Dernière modification par MINOSI (09-05-2014 21:12:32)

Lagaffe · [↑]

Bonsoir,

Au risque de passer pour le grincheux de service ... mais il en faut toujours un ; les textures photos réalisées à partir de FSET ou de SBuilderX sont soumises à copyright ! ... à moins de conserver ces développements pour soi ...

Sans vouloir faire de la PUB pour le tuto de Flying Michel, seulles les Bases ORTHO rendues libres par l'IGN sont diffusables librement.

PS: Retirer complétement les pistes peut rendre le terrain "meuble" et donc l'avion passera au travers dans certains cas. Au pire laisser une piste très très petite pour qu'elle ne soit pas visible ....

MINOSI · [↑]

Bonsoir Didier,

Grincheux ? Alors on serait deux mais deux fois valent mieux qu'une : ce que tu rappelles est également, et en gras, dans mon post.

Pour ce qui est de retirer complètement une piste : je n'ai été jusqu'à tester ce que tu dis mais c'est fort probable. Sans aller jusqu'à la supprimer, on peut tenter de lui attribuer une largeur nulle mais dans ce cas elle n'existe plus pour l'ATC ! Quant à une piste "très très petite" on est d'accord, et pour être précis, FSX considère qu'une piste de 1 centimètre fait un bon runway ! Et tout le monde est content.
Pour éviter le pointillé qui représenterait ce petit cm et surtout pour éviter les triangles qui sont automatiquement générés pour raccorder les taxiways à la piste, il suffit d'affecter à la piste une texture de surface différente.

Dernière modification par MINOSI (09-05-2014 22:52:27)

Marcstrasb · [↑]

Lagaffe a écrit :

Bonsoir,
Au risque de passer pour le grincheux de service ... mais il en faut toujours un ; les textures photos réalisées à partir de FSET ou de SBuilderX sont soumises à copyright ! ... à moins de conserver ces développements pour soi ...
Sans vouloir faire de la PUB pour le tuto de Flying Michel, seulles les Bases ORTHO rendues libres par l'IGN sont diffusables librement.
PS: Retirer complétement les pistes peut rendre le terrain "meuble" et donc l'avion passera au travers dans certains cas. Au pire laisser une piste très très petite pour qu'elle ne soit pas visible ....

Bonjour Didier,

Sans vouloir interférer sur le sujet fort intéressant de MINOSI, l'excellent tuto de flyingmichel ne marche pas trop bien chez moi !

Amitiés,
Marc

FlipFlap · [↑]

Tuto de flyingmichel

#1 [↑][↓] 09-05-2014 05:17:24

[P3D][FSX] En route vers la scène photo-réaliste parfaite ?

#2 [↑][↓] 09-05-2014 12:40:50

Re : [P3D][FSX] En route vers la scène photo-réaliste parfaite ?

#3 [↑][↓] 09-05-2014 13:57:46

Re : [P3D][FSX] En route vers la scène photo-réaliste parfaite ?

#4 [↑][↓] 09-05-2014 21:09:20

Re : [P3D][FSX] En route vers la scène photo-réaliste parfaite ?

#5 [↑][↓] 09-05-2014 21:45:51

Re : [P3D][FSX] En route vers la scène photo-réaliste parfaite ?

#6 [↑][↓] 09-05-2014 22:50:11

Re : [P3D][FSX] En route vers la scène photo-réaliste parfaite ?

#7 [↑][↓] 10-05-2014 08:26:51

Re : [P3D][FSX] En route vers la scène photo-réaliste parfaite ?

#8 [↑][↓] 10-05-2014 16:49:11

Re : [P3D][FSX] En route vers la scène photo-réaliste parfaite ?

Pied de page des forums