Bonjour,
 
Je me demandais comment il était possible d'éviter les calculs d'illuminations inutiles en deferred shading.
 
Je m'explique: dans mon implémentation, l'un des Geometry-Buffers contient la couleur diffuse, et un 4ème paramètre qui est un booléen, "lit". Ainsi cela devrait permettre de ne pas traiter les éléments comme la skybox pendant les phases suivantes (éclairage par exemple) et de gagner pas mal en performances.
 
Problème: avant je dessinais directement dans le framebuffer principal pour la phase d'illumination. Donc avant de commencer les phases de post-processing je dessinais d'abord l'image avec juste la contribution diffuse, puis une deuxième fois avec alpha et stencil test activé, où un shader regardait si "lit" était à faux et ainsi rejetait automatiquement ce pixel. Comme cela en utilisant le stencil test pour les opérations suivantes, seuls les pixels à éclairer étaient traités.
 
Seulement maintenant je ne dessine plus la phase d'illumination dans le frame buffer mais dans une autre render target. Le problème vient du fait que je ne peux apparemment l'utiliser qu'en "color only". Si je lui joins un depth/stencil buffer l'application fait n'importe quoi!  
Donc je ne peux évidemment plus utiliser le stencil buffer pour l'early out test.
 
Actuellement je fais un "discard" (ou "texkill" si vous préférez) quand "lit" est à faux dans les shaders de post-processing...hé bien non seulement c'est moche puisqu'il faut le faire dans chaque shader, en plus je perds en performance au lieu d'en gagner!!
 
Quelqu'un saurait m'aider?

là je t'avouerai que tu as lancé un topic interressant, j'ai pas encore creusé le deferred renderer.
 
il est clair que dans toutes les docs nvidia/ati, le discard/texkill est indiqué comme étant pourri.
 
y'a pas des examples de deferred renderers chez nv & ati pour voir comment ils jonglent avec les rendertargets ?
 

Ben aucun des exemples du SDK que j'ai trouvé n'effectue ce genre d'optimisation.
 
Mais ce qui est curieux c'est que dans la doc de nVidia pour le deferred shading, ils conseillent pour la phase d'illumination:
pour chaque lumière
 - 1/ désactiver l'écriture dans le color buffer, activer celle dans le stencil buffer, dessiner le volume englobant de la zone d'influence de la lumière (genre box pour une directionnelle, sphere pour une ponctuelle)
- 2/ réactiver l'écriture dans le color buffer, désactiver celle du stencil, et ajouter la contribution de la lumière sur les pixels qui passent le stencil test. *
 
Donc ça signifie qu'ils utilisent bien un stencil buffer pour cette phase! Alors est-ce que c'est mon implémentation qui foire? Pourquoi est-ce que j'ai ce bug (image qui reste figée) quand j'utilise une render target de destination avec un depth/stencil buffer attaché?
Et ça le fait aussi bien avec OpenGL qu'avec DirectX!
 
 
* Perso je trouve ça coûteux puisqu'il faut généralement nettoyer le stencil buffer pour chaque lampe!
Je crois que calculer la bounding box de la lumière dans l'image space avec le CPU et changer la zone de scissor est plus performant.
C'est d'ailleurs ce qui est fait dans l'exemple du SDK nVidia ^^