//forward rendering shader pseudocode:
main(){
diffuse = vec3(0)
specular = vec3(0)
for each light "i"{
diffuse+=calculateDiffuse(i, normal,pos,etc);
diffuse+=calculateSpecular(i, ...)
}
}
Forward rendering limitations?
Hi! Maybe i´m missing something very basic here, but i don´t get why forward rendering = few lights, deferred rendering = tons of lights.
Let me explain: in a deferred renderer you have a shader that gets 4 (or more) inputs: color, normals, position (or depth and reconstruct, whatever), specular. These are buffers that cover the entire screen. Then for each light you draw a quad that calculates lighting given the light position and that data.
In forward rendering, you just draw everything using a shader that iterates over the lights calculating per pixel lighting.
What stops you from doing this?:
If you do this using good frustum culling in order to avoid rendering polygons you don´t see, and reuse a fixed number of lights (sorted by distance to objects) over and over again to render each poly with just the nearest lights...why would be impossible to have 2000 lights like you have in deferred rendering? :S
I´m trying to decide if i should stick to forward or deferred, i feel forward is better but everyone seems to love deferred so i must be missing something...
can you help me?
with deferred you should perform fewer per pixel operations
I never jumped on the deferred bandwagon though since it has a few limitations
A/ its slower (say just for the directional light) + requires more memory
B/ its less flexible
C/ depending on hardware u can run into issues eg with AA
I never jumped on the deferred bandwagon though since it has a few limitations
A/ its slower (say just for the directional light) + requires more memory
B/ its less flexible
C/ depending on hardware u can run into issues eg with AA
Quote:why would be impossible to have 2000 lights like you have in deferred rendering?
It's not. But try doing that in a forward renderer and see what kind of performance you'll get.
In order to do what you want, you'd need to know the number of lights you have in advance, and compile shaders for that number of lights. You can't do a 'for' on a variable/uniform in a shader. You say you want 2000 lights? Forward rendering is limited by the hardware limitation of 8 maximum active lights. You'd have to come up with some code that would select the 8 closest / most significant contribution lights affecting each model before you draw it, or revert to multiple draw passes.
With deferred approach you draw lights like geometric objects after you've drawn your scene. Whatever those geometric objects occlude gets lit. Far less headaches and pixel overdraw than with forward rendering. Not to mention quite a bit faster with anything more than 2-5 lights, depending on your setup.
With deferred rendering you also already have access to your depth buffer and screen space normal map for advanced post-processing effects such as screen space ambient occlusion or depth-of-field.
All in all, deferred rendering is just a natural step forward.
With deferred approach you draw lights like geometric objects after you've drawn your scene. Whatever those geometric objects occlude gets lit. Far less headaches and pixel overdraw than with forward rendering. Not to mention quite a bit faster with anything more than 2-5 lights, depending on your setup.
With deferred rendering you also already have access to your depth buffer and screen space normal map for advanced post-processing effects such as screen space ambient occlusion or depth-of-field.
All in all, deferred rendering is just a natural step forward.
thank you guys!
Currently in my setup I already extract normals,depth and velocity buffer because i am using SSAO and motion blur. Then i have a virtual lights setup that finds the N closer lights to the currently rendering node (mesh entity or octree node), and i move there the real opengl lights before forward rendering everything to a half resolution light buffer which I then apply over the unlit colors using a technique similar to inferred lightning´s DSF. So switching to deferred is not very complicated for me.
i can have 10-15 point lights on screen before having noticeable lag, this reduces to 7-12 for area lights. But i need to be able to support at least +100 area lights, and i don´t see the actual technical advantage of deferred over forward, why is it so much faster? is it number of pixels lit per light?
Is it easy to implement, say, spotlights in a deferred renderer? everything i have seen seems to use only point lights...
Currently in my setup I already extract normals,depth and velocity buffer because i am using SSAO and motion blur. Then i have a virtual lights setup that finds the N closer lights to the currently rendering node (mesh entity or octree node), and i move there the real opengl lights before forward rendering everything to a half resolution light buffer which I then apply over the unlit colors using a technique similar to inferred lightning´s DSF. So switching to deferred is not very complicated for me.
i can have 10-15 point lights on screen before having noticeable lag, this reduces to 7-12 for area lights. But i need to be able to support at least +100 area lights, and i don´t see the actual technical advantage of deferred over forward, why is it so much faster? is it number of pixels lit per light?
Is it easy to implement, say, spotlights in a deferred renderer? everything i have seen seems to use only point lights...
I´ve been reading an article that has opened my eyes a bit. It seems the main advantage is that you don´t calculate lighting for pixels that are going to be occluded later, so you don´t waste calculations. Only the pixels you can actually see are lit.
I think i´ll give it a try, after all if it does not convince me i can revert to forward rendering.
I think i´ll give it a try, after all if it does not convince me i can revert to forward rendering.
>>Forward rendering is limited by the hardware limitation of 8 maximum active lights. You'd have to come up with some code that would select the 8 closest / most significant contribution lights affecting each model before you draw it, or revert to multiple draw passes.<<
Actually in the case youre saying there is in fact no real difference between deferred or forward rendering.
i.e. deferred u have to render the lights shape (one per light)
forward rendering u have to render the lights recievers geometry (one per light)
though in both methods its possible (but messy) to collapse multiple lights into fewer passes
>>All in all, deferred rendering is just a natural step forward.
actually its not, Ive given 3 reasons why it can be worse, yes for certain games (eg killzone 2) it can be benificial but for the majority of games its not
>>is it number of pixels lit per light?
yes thats correct, show a screenshot of what youre trying to achieve + then ppl could advise whether or not forward/deferred is a better choice
Actually in the case youre saying there is in fact no real difference between deferred or forward rendering.
i.e. deferred u have to render the lights shape (one per light)
forward rendering u have to render the lights recievers geometry (one per light)
though in both methods its possible (but messy) to collapse multiple lights into fewer passes
>>All in all, deferred rendering is just a natural step forward.
actually its not, Ive given 3 reasons why it can be worse, yes for certain games (eg killzone 2) it can be benificial but for the majority of games its not
>>is it number of pixels lit per light?
yes thats correct, show a screenshot of what youre trying to achieve + then ppl could advise whether or not forward/deferred is a better choice
Quote:Original post by ArenMookYou say you want 2000 lights? Forward rendering is limited by the hardware limitation of 8 maximum active lights.
Hmmm, are you sure you're not confusing "forward rendering" with "fixed-function rendering"? The 8 light limit is a fixed-function thing. Forward rendering using shaders can support as many lights in one pass as you want to throw at it at the cost of shader complexity.
Quote:Original post by zedz
yes thats correct, show a screenshot of what youre trying to achieve + then ppl could advise whether or not forward/deferred is a better choice
I think its better to describe it: i want to simulate one-bounce GI using area lights (actual area lights, not a planar distribution of point lights). So probably i will have quite a lot of them on screen at the same time and each one will cover a large portion of it. I was wondering if instead of using separate geometry for each light would be better to just use a fullscreen quad, after all rarely will a pixel be unlit.
However i also need to support quite high numbers of transparent objects on screen, and that´s a weak point of deferred. I could use the stippling trick from inferred lighting, but... conceptually i find it a bit "hacky".
My forward setup works fine, except it can´t support the light count i need. Sigh.
Quote:Original post by PlayerXQuote:Original post by ArenMookYou say you want 2000 lights? Forward rendering is limited by the hardware limitation of 8 maximum active lights.
Hmmm, are you sure you're not confusing "forward rendering" with "fixed-function rendering"? The 8 light limit is a fixed-function thing. Forward rendering using shaders can support as many lights in one pass as you want to throw at it at the cost of shader complexity.
True, it can if you want to bypass using gl_LightSource and just send a list of your own lights yourself. Shader complexity is a pretty powerful argument in favor of the deferred approach on its own. As for transparent objects, they can be handled either via forward rendering right after the deferred pass, or in a separate deferred pass of their own that will use the depth and color buffers of the previous pass to speed things up. Overlapping transparent objects get tricky with the latter approach though, but then again it's the same with forward rendering.
Most deferred tutorials suggest using a giant G-buffer to store all your data and this can be a detriment for some. You can avoid it by simply using multiple render targets instead. All in all, the biggest argument against deferred shading is the memory requirement. So in the end it's all up to the programmer with which approach will work best for the task at hand.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement