Complex Mask

[marius05]

Il y avait l'option "Complex Mask" dans ortho4xp 1.20, que je n'avais jamais utilisé, mais dont j'ai trouvé l'explication ici :

http://www.pilote-virtuel.com/viewtopic.php?id=83835

Je ne trouve plus cette option dans Ortho4xp 1.30 sur lequel je suis maintenant : est-ce automatique ou faut-il procéder autrement ?

Merci. Marius05

[Oscar Pilote]

Bonsoir Marius,
Oui c'est une option par défaut maintenant. Cela ne l'état pas parce que cela prenait plus de temps,
cela a été parallélisé (et puis avec l'âge on apprend à prendre le temps :-)

[Pascal_LSGC]

Bonsoir Marius,
Oui c'est une option par défaut maintenant. Cela ne l'état pas parce que cela prenait plus de temps,
cela a été parallélisé (et puis avec l'âge on apprend à prendre le temps :-)

Salut Oscar,
J'espère que tu vas bien :-)

Si je me souviens bien, tu avais demandé à Ben Supnik la possibilité de compresser les masques png (texture alpha supplémentaire) en dds. Est-ce que cela a été implémenté au cours d'une version récente ? (j'en doute, je n'ai rien vu dans les notes de version, mais on sait jamais)

Pascal

[Oscar Pilote]

Bonjour Pascal,

Non ils n'ont pas implémenté, d'où la raison de mon essai d'imprimer les masques directement dans les .dds en passant en dtx5. Je n'avais pas fais cela dès le départ d'ortho4xp car la doc X-Plane disait que dxt5 = 2*plus de besoin VRAM que dxt1, et les .png
des masques étaient à résolution bien plus faible que les .dds, ce qui devait constituer le gain par rapport au passage au dxt5. Mais comme les .png n'étaient jamais "mipmappés" par X-Plane, ce gain se traduisait en fait par une perte, enfin c'est ce que j'ai constaté lorsque je me suis décidé à tester en dxt5. En fait ça va au-delà de ça, j'ai l'impression que X-Plane ne consomme pas plus de VRAM en dxt5 (ou plus vraisemblablement qu'il en "gaspille" la moitié quand il est en dxt1...), et donc finalement ce changement me convainc beaucoup.

[Une autre raison qui m'avait arrêté à l'époque c'est que je me disais que si la mer était rognée par le masque dans le dds, un utilisateur ne pourrait pas "étendre" le masque plus loin plus tard s'il le souhaitait. Lorsque j'ai testé j'ai réalisé tout penaud que bien sûr l'image rognée ne disparaît pas du fichier, c'est juste le canal alpha qui est modulé et qui tombe à zéro, mais on peut redécouvrir l'image entière au besoin... on apprend tjs de ses erreurs :-)].

[Pascal_LSGC]

Bonjour Pascal,

Non ils n'ont pas implémenté, d'où la raison de mon essai d'imprimer les masques directement dans les .dds en passant en dtx5.

J'implémente également de mon côté un masque dans le canal alpha du .dds. Comme mon procédé n'utilise pas d'orthophotos et que donc la texture principale est utilisée à plein d'endroits, je place localement des dds à plus basse définition, niveau 14 ou 15, avec le masque dans le canal alpha, et je les utilise comme decal en redirigeant l'alpha vers la texture principale. (c'est puissant, les decals !) Tu pourrais certainement économiser en espace disque avec cette technique, en utilisant dxt1 pour les textures haute résolution, et dxt5 pour les masques à moindre résolution. A moins que tu ne procèdes déjà ainsi :-) L'astuce est qu'il suffit de créer un fichier .ter supplémentaire qui ne sert qu'à la directive LOAD_CENTER pour le dds du masque.

Les masques en png dilapident énormément de VRAM, je crois que tu as constaté toi-même que l'intégralité des png pour les 12 tuiles sont chargés à plein dans la carte graphique. J'espère que Ben implémentera les masques alpha en dds un jour ou l'autre.

Je n'avais pas fais cela dès le départ d'ortho4xp car la doc X-Plane disait que dxt5 = 2*plus de besoin VRAM que dxt1, et les .png des masques étaient à résolution bien plus faible que les .dds, ce qui devait constituer le gain par rapport au passage au dxt5. Mais comme les .png n'étaient jamais "mipmappés" par X-Plane, ce gain se traduisait en fait par une perte, enfin c'est ce que j'ai constaté lorsque je me suis décidé à tester en dxt5. En fait ça va au-delà de ça, j'ai l'impression que X-Plane ne consomme pas plus de VRAM en dxt5 (ou plus vraisemblablement qu'il en "gaspille" la moitié quand il est en dxt1...), et donc finalement ce changement me convainc beaucoup.

Oui, c'est étonnant pour ce qui est de la VRAM. Par contre, sur le disque, la taille du dxt1 est bien la moitié du dxt5.

[Une autre raison qui m'avait arrêté à l'époque c'est que je me disais que si la mer était rognée par le masque dans le dds, un utilisateur ne pourrait pas "étendre" le masque plus loin plus tard s'il le souhaitait. Lorsque j'ai testé j'ai réalisé tout penaud que bien sûr l'image rognée ne disparaît pas du fichier, c'est juste le canal alpha qui est modulé et qui tombe à zéro, mais on peut redécouvrir l'image entière au besoin... on apprend tjs de ses erreurs :-)].

Absolument ! :-)

Bonne soirée,
Pascal

[Pascal_LSGC]

A l'attention de Oscar ou toute personne intéressée par les détails du fonctionnement des shaders, un petit complément sur les decals.
Dans l'instruction avancé ("not for the faint of heart!" dixit Ben):

DECAL_PARAMS <scale> <dither> <r> <g> <b> <a> <m> <k> <r> <g> <b> <a> <m> <k> <texture file>

c'est le paramètre "dither" qui "additionne" l'alpha du decal à celui de la texture principale.

Plus précisément, cette "addition" se passe ainsi, de ce que j'en ai compris:

X-Plane linéarise les valeurs de pixels de chaque texture, par l'inverse de la fonction gamma de l'espace srgb, avant toute opération, y compris le canal alpha (ce qui est correct!).
Chaque canal est donc représenté par une valeur entre 0 et 1. Une valeur de pixel de ~187 (de mémoire) devient la valeur médiane 0.5. (et non pas 127 ou 128 !)

La combinaison finale s'applique:

alpha_lin_rendu = alpha_lin_albedo + dither * (alpha_lin_decal - 0.5)

dither peut avoir n'importe quelle valeur, même négative, par contre je pense que la valeur de "dither * (alpha_lin_decal - 0.5)" est tronquée (peut-être [-1;1] ?).

Bonne journée,
Pascal


P.S: Marius, désolé de détourner ton message avec des considérations techniques

P.P.S: attention, j'ai fais ça de mémoire, mais dans certains cas, l'alpha decal de la formule ci-dessus est pris en négatif, ce qui donne

alpha_lin_rendu = alpha_lin_albedo + dither * (0.5 - alpha_lin_decal)

Je ne sais pas si c'est toujours le cas, ou juste pour l'usage que j'en fais. Il faut tester.

[Oscar Pilote]

L'astuce est qu'il suffit de créer un fichier .ter supplémentaire qui ne sert qu'à la directive LOAD_CENTER pour le dds du masque.

Cela fait deux tracés distincts pour chaque triangle, es-tu certain que ce ne soit pas un peu gourmand ?

Par contre, sur le disque, la taille du dxt1 est bien la moitié du dxt5.

En effet, mais la différence se réduit à peau de chagrin un fois passé en 7z (avec zonephoto en tête), ce qui est assez logique puisque le canal alpha est essentiellement 0 ou 1 sur presque l'intégralité de la texture.

------
Merci pour tes indications sur les décals. X-Plane utilise 2.2 comme valeur de gamma pour le passage en linéaire, donc (187/255)^2.2 cela donne bien environ 0.5 comme tu l'as écrit.

[Pascal_LSGC]

Cela fait deux tracés distincts pour chaque triangle, es-tu certain que ce ne soit pas un peu gourmand ?

Non justement, il s'agit de rajouter un fichier .ter dont le seul but est de charger la texture utilisée "ailleurs" comme decal avec le bon niveau de mipmap. C'est un tour de passe-passe en somme.
L'astuce revient à déclarer à X-Plane qu'on va utiliser la texture à la "façon d'une orthophoto", avec un mipmap dépendant de LOAD_CENTER, mais de n'utiliser celle-ci que comme decal. On profite ainsi d'un chargement graduel -selon la distance- du masque stocké dans le canal alpha du decal.

Trois façon de faire, dont la 1) déjà testée, la 2) dont je suis quasi certain qu'elle fonctionne, et la 3) qui pourrait bien marcher aussi :

1) Déclarer la texture comme BASE_TEX avec la directive LOAD_CENTER dans un fichier .ter. Pointer vers ce fichier ter depuis un seul petit triangle de rien du tout pour toute la zone couverte par le decal. On peut cacher ce triangle "bidon" sous un autre triangle ou sous la jupe de Trudi, c'est égal, seule la prise en compte de LOAD_CENTER importe.

2) Déclarer la texture comme BASE_TEX avec la directive LOAD_CENTER dans un fichier .ter. Faire figurer le ter (ou plutôt son lien virtuel défini dans le library.txt) dans l'index en début de .dsf, mais ne créer aucun triangle qui le référence.

3) Déclarer la texture comme BASE_TEX avec la directive LOAD_CENTER dans un fichier .ter.


J'espère que j'ai été suffisamment clair, n'hésite pas à me demander des détails.

Merci pour tes indications sur les décals. X-Plane utilise 2.2 comme valeur de gamma pour le passage en linéaire, donc (187/255)^2.2 cela donne bien environ 0.5 comme tu l'as écrit.

J'ai constaté que X-Plane utilise une correction du gamma exactement telle que définie dans l'espace de couleurs sRGB. Dans la plus grande partie de la plage, la formule utilisée est Csrgb = 1.055 * Clin^(1/2.4) - 0.055.
https://fr.wikipedia.org/wiki/SRGB#T...XYZ_vers_sRGB), voir sous-chapitre "Correction de gamma".

Bonne soirée,
Pascal

[Pascal_LSGC]

doublon supprimé