Comments on: Forward vs. Deferred Rendering: why/when forward rendering still matters Yep, I remember meeting Richard Geldreich and him explaining some of the intricacies of his Xbox 1 deferred renderer - quite a technical feat. Later, I implemented a deferred shading engine for Perfect Dark Zero, which shipped as an Xbox 360 launch title. It also used a variant of depth peeling for transparencies - I wonder if this is a first? Theoretically at least, depth peeling, or any other number of OIT tricks, mean that deferred shading can be applied to transparencies too. Yep, I remember meeting Richard Geldreich and him explaining some of the intricacies of his Xbox 1 deferred renderer – quite a technical feat. Later, I implemented a deferred shading engine for Perfect Dark Zero, which shipped as an Xbox 360 launch title. It also used a variant of depth peeling for transparencies – I wonder if this is a first? Theoretically at least, depth peeling, or any other number of OIT tricks, mean that deferred shading can be applied to transparencies too.

]]>
By: Jorge Luna/2011/01/18/forward-vs-deferred-rendering-whywhen-forward-rendering-still-matters/#comment-700 Jorge Luna Mon, 24 Jan 2011 15:50:08 +0000 Just answering a few questions:I never tried light pre-pass myself but I would probably try that soon to be able to comment on that! =)1 – Aras, about the Wii, It has some programmable “shading” stages. You can see how that works in this article: One major aspect not mentioned in the Forward vs Deferred argument is overhead. A lot of these decisions stop being choices when costs of shuffling data and dealing with various passes start to come into consideration. A few extra buffer clears don't really hurt a 30Hz console game much, but can actually be devastatingly expensive in a 60Hz title. One major aspect not mentioned in the Forward vs Deferred argument is overhead. A lot of these decisions stop being choices when costs of shuffling data and dealing with various passes start to come into consideration. A few extra buffer clears don’t really hurt a 30Hz console game much, but can actually be devastatingly expensive in a 60Hz title.

]]>
By: Andreas Brinck/2011/01/18/forward-vs-deferred-rendering-whywhen-forward-rendering-still-matters/#comment-697 Andreas Brinck Wed, 19 Jan 2011 14:42:08 +0000 I've worked on games that use Deferred, Forward and Pre-Pass Deferred. Deferred was quite slow because it took up extra Tiles on x360 (due to 4 render targets not fitting in EDO) and you can't enable anti-aliasing. I think it can be a lot faster on PS3 with good use of SPUs for some post processing but we never got our engine to that level.Pre-pass is somewhat faster - only 1 render target and the cost per light is even smaller - but we lost the ability to do parallax and relief mapping. Also you still effectively lose proper anti-aliasing.Forward lighting - doing lots of dynamic lights can get difficult because you need to make sure your landscape is broken into small enough pieces and just apply the closest lights to each piece. If you have lots of close-together dynamic lights you get popping and seams since you have to ignore some sometimes.Overall though, a nice statically lit radiosity+ambient occlusion mapped forward lit landscape will be much faster and look much nicer with a lot less effort to get up and running. Having the ability to fade objects in and out is very useful for LOD'ing and not having to do a Z-Prime can save a lot of time if your main shader isn't that expensive... I'd push for forward lighting as first choice for any project unless it was heavily dependent on dynamic lighting for mood... I’ve worked on games that use Deferred, Forward and Pre-Pass Deferred. Deferred was quite slow because it took up extra Tiles on x360 (due to 4 render targets not fitting in EDO) and you can’t enable anti-aliasing. I think it can be a lot faster on PS3 with good use of SPUs for some post processing but we never got our engine to that level.Pre-pass is somewhat faster – only 1 render target and the cost per light is even smaller – but we lost the ability to do parallax and relief mapping. Also you still effectively lose proper anti-aliasing.Forward lighting – doing lots of dynamic lights can get difficult because you need to make sure your landscape is broken into small enough pieces and just apply the closest lights to each piece. If you have lots of close-together dynamic lights you get popping and seams since you have to ignore some sometimes.Overall though, a nice statically lit radiosity+ambient occlusion mapped forward lit landscape will be much faster and look much nicer with a lot less effort to get up and running. Having the ability to fade objects in and out is very useful for LOD’ing and not having to do a Z-Prime can save a lot of time if your main shader isn’t that expensive… I’d push for forward lighting as first choice for any project unless it was heavily dependent on dynamic lighting for mood…

]]>
By: ivanassen/2011/01/18/forward-vs-deferred-rendering-whywhen-forward-rendering-still-matters/#comment-695 ivanassen Wed, 19 Jan 2011 11:29:35 +0000 COD:BLOPS doesn't use deferred rendering, it's still a forward renderer. COD:BLOPS doesn’t use deferred rendering, it’s still a forward renderer.

]]>
By: Aphrodite3D/2011/01/18/forward-vs-deferred-rendering-whywhen-forward-rendering-still-matters/#comment-693 Aphrodite3D Wed, 19 Jan 2011 08:28:57 +0000 Deferred rendering has at least one more drawback. It's not easy to implement light groups. In our engine the user can select what objects each light should lit. This is easily done with a forward renderer. Not so easy with a deferred one. It's could be implemented but not AFAIK without increasing the G-buffer size and increasing pixel shader complexity.That being said, I still think that we'll support deferred rendering in some manner fairly soon. Deferred rendering has at least one more drawback. It’s not easy to implement light groups. In our engine the user can select what objects each light should lit. This is easily done with a forward renderer. Not so easy with a deferred one. It’s could be implemented but not AFAIK without increasing the G-buffer size and increasing pixel shader complexity.That being said, I still think that we’ll support deferred rendering in some manner fairly soon.

]]>
By: Nick Darnell/2011/01/18/forward-vs-deferred-rendering-whywhen-forward-rendering-still-matters/#comment-691 Nick Darnell Wed, 19 Jan 2011 07:46:35 +0000 Like always, choice of one or another depends on the situation; there's no definitive answer to which one is better.I'm not sure I buy "old hardware does not support MRTs" and "for the consoles" in the same sentence though. All current shader-capable consoles (Xbox 360 & PS3) do support MRTs. And the Wii is not very much shader capable, so...There are also alternative approaches, e.g. light pre-pass (aka deferred lighting) that do not necessarily require MRTs. You can do light pre-pass using one color target (normals + specular exponent) if your platform supports reading depth buffer as a texture. All shader capable consoles support sampling depth buffer as a texture, as well as most desktop GPUs (in OpenGL, attach depth component texture to FBO depth attachment; in D3D9 use FOURCC hacks of INTZ/RAWZ). I tried the same on iOS the other day, and it works even there as well.But yeah, of course forward rendering is still a very valid approach for a lot of cases. Like always, choice of one or another depends on the situation; there’s no definitive answer to which one is better.I’m not sure I buy “old hardware does not support MRTs” and “for the consoles” in the same sentence though. All current shader-capable consoles (Xbox 360 & PS3) do support MRTs. And the Wii is not very much shader capable, so…There are also alternative approaches, e.g. light pre-pass (aka deferred lighting) that do not necessarily require MRTs. You can do light pre-pass using one color target (normals + specular exponent) if your platform supports reading depth buffer as a texture. All shader capable consoles support sampling depth buffer as a texture, as well as most desktop GPUs (in OpenGL, attach depth component texture to FBO depth attachment; in D3D9 use FOURCC hacks of INTZ/RAWZ). I tried the same on iOS the other day, and it works even there as well.But yeah, of course forward rendering is still a very valid approach for a lot of cases.

]]>