Salut à tous,

Les vacances de Noël sont arrivées et je suis évidemment de retour !

J´ai recommencé à jouer dans mon petit framework. Grâce au gourou Nehe, c´est plutôt simple d´apprendre à connaitre de nouvelles fonctions.

Cela dit, j´ai frappé un mur avec le blending. En bref, le site de Nehe dit que...

Pour blender correctement, il faut trier, afin d´en faire le rendu, les polygones du plus loin au plus proche ( donc de celui dont la valeur en z est la plus petite jusqu´à celui qui a la plus grande) sans désactiver le GL_DEPTH_TEST qui, si je comprends bien, fait généralement en sorte de couper le rendu des polygones qui sont masqués par d´autres.

Or, le projet exemple de Nehe n´offre qu´un cube qui tourne avec le GL_DEPTH_TEST désactivé.

Afin de comprendre la logique d´un blending fait " correctement", j´ai voulu faire un tri du plus profond au plus proche sur ma caisse qui tourne sur elle-même.

Ça fonctionne ! Mais seulement au tout début, soit pour le court instant où mon tri est vrai ( c´est à dire que, en faisant une rotation sur elle-même, les polys changent inévitablement de position et celui le plus proche de l´utilisateur devient lentement celui qui est le plus loin).

J´aimerais savoir comment solutionner ce problème. Je vois mal comment faire du sorting sur les faces du cube sachant qu´ils subissent une rotation par une matrice glRotatef().

Merci bien !
Joyeux Noël !

il est en effet important de trier les polygones transparents pour obtenir le rendu souhaite.
Pour ce qui est du z-buffer, actif ou pas, deux philosophie : desactiver l´ecriture quand on dessine des polys transparents ( marche bien si on les dessine en dernier, apres tout ce qui est " solide"), desactiver le test, comme tu as du le voir dans l´exemple.
Pour le tri, par de miracle : si tu utilises une simple rotation locale pour tout ton modele, il va falloir revoir et complexifier legerement la chose. Tu peux par ex. pour chaque poly transparent retenir son barycentre et calculer les positions relatives a la camera de ces derniers uniquement pour trier tes faces.

Avant de t´exposer la solution, un petit cours de maths :

tu as un point x,y,z.
tu as une caméra a une position < plouf>
ce que tu veux, toi, c´est la position

x2,y2,z2, dans le repere de la caméra : ou x2,y2 seront la coordonnée dand le frustrum, et z2 la position relative de ton polygone
c´est sur z2 qu´intervient le z-buffer, autrement dit, si tu as z2, tu peux faire ton tri.
( apres, openGL calcule x3,y3, ( z3) pour obtenir la position x3,y3 qui sera sur ton écran)

Donc toi, tu veux x2,y2,z2 :

c´est tres simple :

( x2,y2,z2) = Matrix_View * ( x,y,z)

et ta matrix_view est a jour juste apres que tu appelles ton glRotate ( qui ne fait que mettre a jour ta matrix_view)

Techniquement : juste apres ton glRotate, tu fais :

glMatrixMode(GL_MODELVIEW);
ensuite, soit tu calcules a la main en récupérant la matrice ( avec glGet() )
soit tu triches et tu utilises :
glMultMatrix
en chargeant des valeurs bidons dans les autres colonnes que la premiere.

oups, en me relisant, je me dis qu´il faudra peut etre traiter sur z3 et non z2.

car x2,y2,z2 te donnent tes points dans un repere absolu 0,0,0

il faut que tu rajoutes :

( x3,y3,z3) = Matrix_projection * ( x2,y2,z2)

Je vois ! Whew, en conclusion c´est pas mal de travail en perspective .

Merci beaucoup et un dernier joyeux Noël .