Discussion :

[coupecoupe]

Bonsoir,
Deux questions, proches, premièrement quelle est la manière correcte de gérer la transparance en OpenGL forward-compatible, est-ce de mettre une valeur d'alpha entre 0 et 1 pour la couleur en sortie du fragment shader, et paramétrer les choses comme avant en dehors du shader ? ou bien faut-il récupérer la valeur précédente du pixel et faire le mix dans le fragment shader ?

Ma deuxième question est (même dans le cas ou la première réponse serait d'utiliser l'alpha) comment dans le fragment shader (jutilise actuellement GLSL 1.30 et 1.20) récupérer la valeur précédente du pixel ? (par exemple pour faire des mix perso autre que de la transparance)

[Robxley]

Salut,

Pour ta première question, les deux méthodes sont possibles.
La première avec les commandes glEnable(GL_BLEND), glBlendFunc, glAlphaFunc qui fera le mélange en fonction de la valeur alpha de tes pixels en sortie de ton fragment shader. Inconvénient comme tu le cites l'ordre de dessin des objets à son importance.
Ou 2ème méthode tu mélanges toi même tes pixels dans ton fragment shader.

Pour ta deuxième question, pour pouvoir récupérer la valeur précédente d'un pixel il faut utiliser les FBO (Frame buffer object). En faite tu stockes l'ensemble de ta scène dans une(des) texture(s) (stockage colormap et (ou) depthmap si ta surface transparente est derrière tu ne fais pas le mélange couleur), ce qui te permet par la suite de l'utiliser dans ton fragment shader.

Petit exemple : tu dessines l'ensemble de ta scènes ne contenant aucun objet transparent que tu sauvegardes dans un FBO. Deuxième passage, tu dessines tous les objets transparents en les mélangeants avec les pixels concernés.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
uniform sampler2D fboColorMap;
void main()
{
     vec2 coordPixel = gl_Position;/*il y a une transformation a faire pour correspondre aux coordonnées texture à voir sur le net*/
     vec3 pixelColor  = texture2D(fboColorMap, coordPixel);
 
      gl_FragColor = pixelColor*0.5f+gl_FrontColor*0.5f; /*mélange équilibré*/
 
      /*tu peux aussi utiliser la composante alpha*/
      float alpha = gl_FrontColor.a;
      gl_FragColor = pixelColor*(1-alpha)+gl_FrontColor*alpha;
}

Il y a surement d'autre solution, tout dépend de ce que tu cherches à faire.

L'avantage de la deuxième méthode c'est que tu peux simuler la réfraction d'une surface comme quand tu regardes à travers une vitre déformée.
De mémoire c'est similaire aux méthodes de bump mapping mais au lieu d'avoir une texture quelconque c'est ta scène enregistrée dans un FBO que tu déformes à l'aide d'un effet similaire au bump mapping.

[coupecoupe]

utiliser un FBO me parrait compliqué, n'est-il vraiement pas possible de récupérer le pixel précédent plus simplement dans le fragment shader ?
(mais c'est vrai que j'ai relu les specs 2 fois, et je n'ai effectivement pas trouvé)

D'autre part glAlphaFunc a l'air d'être une fonction obsolète, que doit-on utiliser à la place ?

[Robxley]

Malheureusement, je ne crois pas qu'il y aie d'autres solutions que les FBO pour récupérer la valeur d'un pixel précédent.

glAlphaFunc a effectivement de forte chance d'être obsolète avec la Opengl 3.1+ à confirmer avec la doc.

[baton]

Bonjour,

Avec cette technique on pourrai facilement faire du motion blur non?

[Robxley]

Salut Baton,

Oui effectivement pour le Montion blur de mémoire c'est aussi des FBO qu'il faut utiliser. Il y a plein d'info sur les moteurs de recherche pour le Montion blur et Opengl.

De toute façon, tout post traitement (ex:Motion blur) requière quasiment tout le temps des FBO vu qu'un post traitement comme son nom l'indique est effectué sur le traitement déjà calculer, donc ici le rendu de la scène qui est sauvegardé sur un ou plusieurs FBO.

[ShevchenKik]

Bonjour,

sans utiliser de FBO, il reste la possibilité de récupérer la valeur alpha du "pixel précédent", mais pas sa couleur.

Par exemple, tu peux utiliser ca pour créer des masques, en réglant le blending sur GL_DST_ALPHA ou GL_ONE_MINUS_DST_ALPHA, en fonction de ce que tu veux obtenir.

ATTENTION: il n'y a pas de destination alpha si tu utilises le driver OpenGL 1.1 de Windows (software).

Par contre, si il te faut vraiment la couleur du pixel précédent, je ne vois pas trop d'autre solution que de faire un prérendu offscreen (avec FBO, pBuffers, etc...)

[LeGreg]

Le pourquoi du comment on ne peut pas récupérer la valeur précédente du pixel dans le pixel shader (Enfin en simplifiant beaucoup..) :
Les cartes graphiques modernes sont hautement pipelinées afin de garantir de hautes performances. Il peut donc y avoir de nombreux triangles, sommets, pixels, en cours de traitement ("in flight") au même moment.
Pour préserver ce parallélisme il ne faut pas autoriser le pixel courant à lire le pixel précédent sans quoi il faudrait s'assurer que personne ne puisse commencer une tâche de traitement sans que les autres aient fini (sérialisation). En théorie bien entendu c'est possible (certains hardwares fonctionnent comme cela) mais la norme OpenGL a été conçue pour être inclusive de tous les hardware et imposer ces restrictions semblait trop limitatif.

Pourquoi c'est possible avec les fonctions de blending/raster ops alors ? Ces fonctions sont "fixed", non programmables donc peuvent être implémentées de manière efficace (nombre d'opérations connu à l'avance) en tirant partie du Read/Modify/Write de l'opération d'écriture dans le frame buffer.

L'inconvénient est bien évidemment le ping ponging, nécessité de faire des allers retours entre textures de rendu quand on veut un peu de flexibilité. Il n'est pas envisageable de faire de la transparence (de particules par exemple, effet de fumée ou étincelles) autrement qu'avec du blending (ping ponging prohibitif). En échange en faisant du render to texture, il est possible de faire des choses bien plus compliquées comme accéder aux pixels voisins, avoir du branchement, des maths compliquées, lire d'autres textures etc.

La frontière est devenue un peu plus floue depuis que les shaders peuvent accéder en lecture et en écriture à des ressources globales. Bien entendu ces ressources globales ont leurs propres limitations notamment le fait que le programmeur devient responsable des accès concurrents.

LeGreg

[Robxley]

Merci pour ce petit topo LeGreg vraiment très intéressant.