I am doing a research on deferred rendering since I will probably want that type of rendering in my game. Now I think I know how is it supposed to be done but most articles and tutorials that I red were either deferred lighting or deferred shadowing it was never both at the same time. Why is this? I think it was Epic's Samaritan demo that said it uses fully deferred rendering. Which deferred rendering is actually better between the two? Is there a benefit in using both at the same time (deferred lighting and shadowing)?
deferred rendering question(s)
Deferred lighting is probably more aptly named light pre-pass, since it's not as easily confused with deferred shading. There is no advantage to light pre-pass compared to deferred shading, the exception being when you want to bring deferred rendering to a platform that doesn't support MRT or simply doesn't have enough frame buffer memory to support a full G-buffer. In fact, light pre-pass will limit you some what.
Deferred shadowing is an orthonormal technique. You can use it even in a forward rendering engine, which I believe UE3 uses even in DX9.
There are basically two commonly used deferred rendering techniques out there.
Those are the (Classic)Deferred Shading approach and Light-Pre-Pass (or sometimes called Deferred Lighting).
- The classic approach, which is being used in the recent unreal engine builds and e.g. frostbite 2.0, is rendering everything you'd need to shade your geometry to a so called G-Buffer (the G-Buffer or geometry pass), then read this data in a second pass, but this time using a fullscreen quad (as a post effect) to do your lighting and shade your final pixel.
- Deferred Lighting or Light-Pre-Pass is different in that you try to minimize your G-Buffer data to maybe depth and normals only. Then in the second pass you don't finish your final shading but rather render out parts of the light equation, which you then use in a third pass (which is a second geometry pass!) to completely finish the shaded scene.
More info's here: http://diaryofagraphicsprogrammer.blogspot.de/2008/03/light-pre-pass-renderer.html
Deferred Shadows are actually something completely different. What you do here is instead of doing the geometry pass and at the same time calculating and applying your shadows, you render those shadows as a post-effect (fullscreen-quad) to a RenderTarget, which you can then read in your lighting/material shader to apply the shadows.
The advantage here is like the above deferred rendering techniques, that you can decouple your shading from the geometry.
Which one of those techniques above is better depends very much on what you are trying to achieve. Light-Pre-Pass is quite common on consoles afaik because of it's low memory bandwidth requirements (e.g. CryEngine 3). As I wrote earlier it has the disadvantage of having to render your entire geometry a second time. So theoretically you would be better of with a classic deferred shading approach if you are expecting a huge amount of polygons in your scene. People always find good ways to optimize for stuff like this though 
Personally if you were to develop something for the PC right now I don't see the point in not choosing a full deferred shading approach of these two.
Since you're not likely to be extremely limited by memory bandwidth or fillrate.
aah, terminology...
In my experience deferred lighting is synonymous with light pre-pass: render thin g-buffer, perform light pass, re-render all geo another time reading lighting information in from light buffer. Advantages include less fillrate hit during gbuffer pass, easier material flexibility, possibility for tricks like inferred rendering for easy MSAA support and alpha lighting, downsides include rendering all geo an additional time.
deferred shading in contrast often refers to rendering a full fat g-buffer, performing light pass, and then just compositing material data in g-buffer and lightbuffer together in fullscreen single pass.
deferred shadows is orthogonal to these, and refers to not applying the shadow to the geometry, but in screen space by reconstructing positions from depth.
Of course, keep in mind that different people use different terminology.
have to be careful with full defered. in my experience you have quickly crippled the smallest graphics cards. I worked with a full defered engine and it was running an empty scene at 2 FPS on an integrated intel something 5000. but at more than 200 on a FireGl8800, and a GTX570. Also some older stuff like 9600M would really dislike this engine. some middle range cards would only get 10/15 fps. whereas on the heavy monsters you could get away with any bloat, its crazy.
So what I mean here, is be careful about the target. bandwidth limitation is one that bites the butt.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
