Hi, I'm trying to create a program in DirectX-11 that implements several techniques, namely Deferred rendering, Phong Tessellation and Shadow mapping. I have had no problem making phong tessellation and Shadow-Mapping, but that was with Forward Rendering, so now that I am looking into Deferred Rendering, I am a bit confused at how to implement and at what stage to implement these techniques.
What I think is that Phong tessellation will be applied in the Geometry pass, and shadow-mapping in the light pass? I think I understand phong tessellation in geometry pass, but how does one create a depth buffer in the light pass if you don't have the geometry information? And what about Phong lighting? Is that just a post process effect? Thank you in advance if you can shed some more light on how to implement other shading techniques with deferred rendering.
Logic of Deferred Rendering combined with other Shading techniques
NisseLund said:
What I think is that Phong tessellation will be applied in the Geometry pass, and shadow-mapping in the light pass? I think I understand phong tessellation in geometry pass, but how does one create a depth buffer in the light pass if you don't have the geometry information? And what about Phong lighting? Is that just a post process effect? Thank you in advance if you can shed some more light on how to implement other shading techniques with deferred rendering.
Deferred rendering splits rendering into two steps. First, you create a “gbuffer”, that contains all the necessary information that you need to calculate lighting later on - that is, positions, normals, material-information etc… for all the objects. This also creates the depth-buffer, in fact for a performant deferred renderer you will want to simply use the depth-buffer to calculate positions for the lighting-pass, as this saves tons of bandwith.
Then you calculate the shadow-maps just like you would for forward. And in the lighting-pass, you have access to the depth-buffer from the deferred rendering pass. So not sure what exactly you are missing.
I have to point out, btw, that classical deferred is really outdated. There are lots of techniques which are much more modern. One that I want to point out, because I like it personally very much, is “clustered shading”. https://www.humus.name/Articles/PracticalClusteredShading.pdf
While this is also a few years old by now, and probably outdated as well, it does have a few advantages. What I liked about it the most is how similar the shader/rendering-code for deferred and forward are. You can reuse the same structures and logic for calculating the lights in both formats, only that for forward you invoke the clustered calculation directly, and for deferred you apply in the sort-of-postprocessing lighting-pass. Also makes it easy to maintain both render-paths without much complications to your renderer, and contrast/compare, or even switch them depending on how scenes are setup, for example. But it might be a bit harder to understand/implement at first, especially if you have never fully done a deferred renderer before. But when it clicks, it is pretty nice ?
@Juliean Ok thank you. I think that the way you “calculate the shadow maps just like you would in forward rendering” seems like it defeats the purpose of splitting it up into two stages, since my shadow mapping uses both meshes and lights, but I read this entry where they seem to have the same question as me https://gamedev.stackexchange.com/questions/25436/shadows-in-deferred-rendering and the consensus they come to is that it still saves some performance.
As for why I'm doing deferred, its a requirement for a project I'm doing in class, so I didn't really choose it myself.
NisseLund said:
@Juliean Ok thank you. I think that the way you “calculate the shadow maps just like you would in forward rendering” seems like it defeats the purpose of splitting it up into two stages, since my shadow mapping uses both meshes and lights, but I read this entry where they seem to have the same question as me https://gamedev.stackexchange.com/questions/25436/shadows-in-deferred-rendering and the consensus they come to is that it still saves some performance.
Not entirely. Even if shadow-mapping uses meshes, it can still use a much simpler representation. One thing that you'd usually do, is put positions into a separate vertex-buffer, and bind only this buffer to the shadow-mapping stage. So you again save lots of bandwidth.
Since you seem to be doing tesselation, this might make things more complicated. If you have many shadow casting-lights, then you might consider doing some sort of transform-feedback, and do one pass where the meshes are tesselated, store that into a vertex-buffer and reuse that for the rest of the passes. But I've never done that myself, and I can't comment from a practical standpoint if this is really faster.
