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)



=> 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é.



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.



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".




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 ?



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 06:40:24)