[DirectX] problème z-buffer & alpha-blending

[kwxyz]

Bonjour a tous,

Je fais mes premiers pas avec DirectX et je me retrouve confronté à un problème illustré par les deux screens suivants.

http://kwxyz.ifrance.com/srcshoot1.png
http://kwxyz.ifrance.com/srcshoot2.png

Il s'agit là de deux quads texturé tout ce qu'il y a de plus banal avec activation de l'alpha blending.

Si je fais le rendu du personnage le plus proche de l'écran en dernier, tout va bien (premier screen), mais si je fais son rendu après celui qui se trouve derrière, j'obtiens le résultat du second screen. J'aurai pensé que ce problème aurait du être reglé par l'utilisation du z-buffer. Puis a la vue de ce résultat, je me suis dit que le z-buffer n'operait peut-ête que sur la géometrie des primitives et ne tenait pas compte des parties transparentes lors du blending qui je crois si situe bien plus tard dans le pipeline directX. Si quelqu'un pouvait affirmer ou infirmer cette hypothèse, je n'aime croire que j'ai compris lorsque je dis dit des aneries ! lolll

Ensuite, y-a-til une solution à ce problème de débutant autre que de trier les quads comportant des parties transparentes par leur composantes z (qu'il faudrait ramener dans l'espace de la caméra). Ca me semble bien lourd juste pour ca... Surtout les calculs matriciels pour convertir la composante z...


Merci à tous ceux qui pourront éclairer ma lanterne

Fred.

[Loulou]

T'as tout compris, les polygones non-opaques doivent être triés du plus lointain au plus proche, et être rendus après la géometrie opaque.

Le phénomène que tu constates a une explication simple : ton pixel, aussi transparent soit-il, est un pixel. Il est donc écrit dans le Z-Buffer et tout ce qui est derrière est rejeté. La solution facile s'il s'agit juste d'une transparence complète (comme ça semble être le cas) est d'utiliser l'alpha-test, qui lui va bien rejeter les pixels transparents plutôt que les écrire inutilement.

[grob1212]

Je tiens également à apporter une précision. On a tendance à voir des personnes se borner à chercher des solutions avec le Z-Buffer. Je rappelerais simplement que dans un contexte général, le Z-Buffer n'est qu'un "mécanisme" qui rejette les pixels situés derrière la scène en cours de rendu (une sorte de clipping au niveau pixel). En ce sens, il n'a pas un caractère indispensable, même si dans certaines situations, il semble difficile de s'en passer.

[kwxyz]

Loulou quand tu parles de transparence complete, c'est bien lorsque les parties transparentes le sont complètement et dans ce cas tu dis que je peux utiliser l'alpha test. Si je paramètre l'alpha test pour rejetter les pixels transparents, il n'y aura pas d'écriture sur le z-buffer, c'est ca ? Et je pourrais rendre mes primitives dans n'importe quel ordre ?

Le truc, c'est que j'ai bien vu un render state pour l'alpha test, mais je ne savais pas ce que c'était, je vais fouiller pour voir comment l'utiliser

Et si ce n'est pas une transparence complète, alors je dois trier mes primitives, ok. Mais c'est à moi de faire les conversions matricielles pour pouvoir les trier ?

Merci pour ces explications

[Loulou]

Loulou quand tu parles de transparence complete, c'est bien lorsque les parties transparentes le sont complètement et dans ce cas tu dis que je peux utiliser l'alpha test. Si je paramètre l'alpha test pour rejetter les pixels transparents, il n'y aura pas d'écriture sur le z-buffer, c'est ca ? Et je pourrais rendre mes primitives dans n'importe quel ordre ?

Oui.

Le truc, c'est que j'ai bien vu un render state pour l'alpha test, mais je ne savais pas ce que c'était, je vais fouiller pour voir comment l'utiliser

Basiquement ça ressemble à ça (de tête) :

Code: Tout sélectionner

device->SetRenderState(D3DRS_ALPHATESTENABLED, true);
device->SetRenderState(D3DRS_ALPHAREF, 0);
device->SetRenderState(D3DRS_ALPHAFUNC, D3DCMP_GREATER);

Vérifie la fonction de comparaison, je ne me rappelle jamais s'il s'agit des pixels qui seront rejetés ou gardés.

Et si ce n'est pas une transparence complète, alors je dois trier mes primitives, ok. Mais c'est à moi de faire les conversions matricielles pour pouvoir les trier ?

Je ne sais pas ce que tu entends par conversion matricielle, mais globalement oui.

[kwxyz]

Merci pour tes réponses loulou

Sans vouloir abuser , tu aurais la reponse à ma dernière question ?

Et si ce n'est pas une transparence complète, alors je dois trier mes primitives, ok. Mais c'est à moi de faire les conversions matricielles pour pouvoir les trier ?

je dois faire moi-même les conversions ?

[edit] tu as été plus rapide que moi
Ce que j'entends c'est que je dois transfermer les coordonnées de mes objets exprimés dans l'espace du monde dans l'espace de vue, ce ne se fait pas par une multiplication avec la matrice de la camera ca ?

[edit 2] Effectivement, le terme était mal choisi... désolé.

[Loulou]

Pourquoi pas plus simplement la distance entre la caméra et l'objet ? Normalement tu as la position de ces 2 choses, donc c'est immédiat.

[kwxyz]

En tout cas la technique avec l'alpha test fonctionne parfaitement comme je le veux.
Du coup, je peux même désactiver l'alpha blending dans ce cas...

Quand a l'utilisation de la distance entre l'objet et la camera, tu dois surement avoir raison, mais je n'arrive pas à me convaincre que l'ordre défini sera dans tous les cas correct, en particulier avec des objets très grands... Mais c'est une idée que je creuserais... De toute facon, pour l'instant, je m'en fiche, je commence par de la 2D donc pas de pb...

Merci

[Loulou]

De toute façon il n'y a pas de feinte : si tu as des objets très grands ou qui se croisent, il vaut parfois mieux laisser quelques bugs que de perdre énormément de temps à faire un tri parfait. Encore hier j'ai vu ce genre de bug dans Dark Messiah of Might and Magic, c'était assez moche.