9 replies to this topic

[starstutter]

Ok, so I think the question that is becoming almost as popular as "How I m8ke teh 733t MMO?" is - Should I use deferred shading?

I know it depends on the type of game you're making, but I'm trying to make my engine somewhat general purpose. I've searched all over the net and formed a list of ups and downs. Maybe you can stop me if any are wrong (and or misunderstood) and overall, say whether or not it is really worth it.

Advantages:

- light count is much less important

- Screen space ambient occlusion and other post-process effects fit right in to the rendering pipeline

- since all the texture enhancment is also done as a post process, things like relief and parallax mapping are substantially cheaper and can be applied to the entire scene (uniformity is good for a natural look). This makes for some very nice "depthy" visuals

- global illumination becomes somewhat trivial

- scene complexity, geometry wise, has little overall effect on the speed

- Geometry batching is easier (duh)

- Volumetrics get a bit easier (I think)



Disadvantages:

- Huge memory bandwith (which is not a significant problem with newer PC's)

- Speed starts out low

- Forces a single lighting model on the entire scene

- Almost impossible not to use Dynamic branching, not old hardware friendly and can be very slow

- Alpha blending is a *&#$!@# nightmare!

- Anti alias is impossible, and post-process alternatives are rather slow


I don't have a real specific game in mind, but I do want to gear the engine toward darker, high contrast games (ie Unreal Engine). Is it worth all the trouble it causes? It just looks so attractive, but it might be an abusive spouse if I go with it :(

EDIT: Btw, does anyone know if Gears of War uses deferred shading?

[Reedbeta]

[quote name='starstutter']Advantages:
- light count is much less important
[/quote]

Yes, it has more to do with how many pixels in screen-space the lights cover.

[quote]
- Screen space ambient occlusion and other post-process effects fit right in to the rendering pipeline[/quote]

Actually many post-processing effects (including SSAO, I believe) work just as well with normal forward shading as they do with deferred shading.

[quote]
- since all the texture enhancment is also done as a post process, things like relief and parallax mapping are substantially cheaper and can be applied to the entire scene (uniformity is good for a natural look). This makes for some very nice "depthy" visuals
[/quote]

I could be wrong, but I'm pretty sure relief and parallax mapping are just as expensive with deferred shading as they are with forward shading. These kinds of things are *not* done as a postprocess. In deferred shading you do all the texture lookups in the first pass and store the returned texture color and normal in the fat buffer, so all relief and parallax mapping would be done in that first pass.

[quote]
- global illumination becomes somewhat trivial
[/quote]

Sorry, global illumination is never trivial (It might still be easier in a deferred shading framework; I've never really looked into it.)

[quote]
- scene complexity, geometry wise, has little overall effect on the speed
[/quote]

To make this statement more precise: you don't have to process the geometry multiple times when it's lit by multiple lights, so it can vastly reduce your vertex costs. Thus you can have greater scene complexity without making the renderer vertex bound.

[quote]
- Geometry batching is easier (duh)
[/quote]

Yep. To amplify, this is because you don't have to split up geometry batches depending on what kind of lights are shining on them; you only have to split them up depending on material properties, whether or not they use normal mapping, whether or not they use parallax mapping, etc.

[quote]
- Volumetrics get a bit easier (I think)
[/quote]

I don't really know any reason why they would be easier in deferred shading.


[quote]
Disadvantages:

- Huge memory bandwidth (which is not a significant problem with newer PC's)
- Forces a single lighting model on the entire scene
- Speed starts out low
[/quote]

Yes, though I'm not sure what you mean by "speed starts out slow"...if you mean it's slowish for small scenes, that's true; you see the most savings vs. forward shading with large scenes.

[quote]
- Almost impossible not to use Dynamic branching, not old hardware friendly and can be very slow
[/quote]

I'm not sure where you're getting that dynamic branching idea about, but I've worked on a deferred shading engine and we NEVER used pixel shader dynamic branching. Really, I don't know any reason why branching would be required to do deferred shading.

[quote]
- Alpha blending is a *&#$!@# nightmare!
[/quote]

Hehe, yes, though it's also a nightmare for forward shading systems. But it's true that transparency in general doesn't fit into deferred shading very nicely. The engine I worked on used a forward-shading pass to do all the transparent stuff after the deferred pass was done.

[quote]
- Anti alias is impossible, and post-process alternatives are rather slow
[/quote]

Super-sampled AA can still be done, but as you mentioned, that's slow. Multi-sample AA, it's true, is not supported by hardware for fat buffers (as far as I know). This could change in the future though.

To sum, I come down in favor of deferred shading generally, but because of an advantage you didn't mention: development cost. Suppose you have n different kinds of materials (regular, normal mapped, parallax mapped, etc.) and m different kinds of lights (point, spot, projective, etc.); then with forward shading you have to write, optimize, and maintain approximately n*m different shaders, i.e. one for each combination, while with deferred shading you only need n + m shaders, which is usually substantially less. That's the most important advantage of it in my mind, because every minute you don't spend maintaining n*m different shaders is a minute you can spend making your game better.

[Blaxill]

Quote

Alpha blending is a *&#$!@# nightmare!

There are new techinques appearing, humus.ca has some very nice examples

Reedbeta said:

Super-sampled AA can still be done, but as you mentioned, that's slow. Multi-sample AA, it's true, is not supported by hardware for fat buffers (as far as I know). This could change in the future though.

Although I can't remember exactly how, this is supposibly possible with DX10.1. (From stricter/better control over sampling etc)

[starstutter]

Reedbeta said:

Actually many post-processing effects (including SSAO, I believe) work just as well with normal forward shading as they do with deferred shading.

Idk about that really... SSAO requires the normal and world position in screen space (well, if you're not doing a purley depth based approach). In forward, these have to be re-constructed, in deffered shading, the info is already prepared and easy to access

Reedbeta said:

I could be wrong, but I'm pretty sure relief and parallax mapping are just as expensive with deferred shading as they are with forward shading.

I could be wrong as well, but I would think that the scale and mathematics would stay the same, and be cheaper compared to forward shading because there is no extrmley expensive overdraw. The only problem I forsee is that there could be artifacts on the borders between objects.

Reedbeta said:

Sorry, global illumination is never trivial :D (It might still be easier in a deferred shading framework; I've never really looked into it.)

srry, I think I worded that wrong :P . What I had going through my mind was simillar to SSAO as in the current pixel takes samples from others around it in world space (this is including an additional reverse culled texture). I think it could provide some cool short range lighting effects. I'm just sure I've seen an algorithem like that somewhere.

Reedbeta said:

I don't really know any reason why they would be easier in deferred shading.

Once again, my experience is limited with DS, but it seems like you could treat fog and light beams (ect ect) in screen space as well. A similar process to lighting only view dependant. Maybe it would only really work for bricks of fog though.

Reedbeta said:

Yes, though I'm not sure what you mean by "speed starts out slow"...

I think you pretty much said it right. Drawing a complex scene isn't a far cry from drawing a blank screen in terms of speed, which I guess could be annoying but a constant fps is nice.

Reedbeta said:

I'm not sure where you're getting that dynamic branching idea about, but I've worked on a deferred shading engine and we NEVER used pixel shader dynamic branching. :) Really, I don't know any reason why branching would be required to do deferred shading.

Above you mentioned doing DS in multiple geometry passes. Is this what you were reffering to? A lot of the papers I've read claim you have to have some kind of DB color regognition to determine the materials of each object as a post process... but you're method sounds way better :P

Reedbeta said:

The engine I worked on used a forward-shading pass to do all the transparent stuff after the deferred pass was done.

I had a similar thought to solve this problem. The only thing I am concerned about is doing too much blending, because that would kind of remove a lot of the advantages of DS (having so many redraws and other lighting models). When you think about the technicalities of it all, I find it pretty impressive how 2K managed to do so much blending with DS in Bioshock (reffering to water of course).

Reedbeta said:

with forward shading you have to write, optimize, and maintain approximately n*m different shaders, i.e. one for each combination, while with deferred shading you only need n + m shaders.

Strange I didn't mention that actually, compacting the rendering pipline is a VERY attractive advantage. I was thinking that with DS, it would become much easier to optimize because it's pretty obvious where the bottlenecks are located.



All in all, I think that the future of DS is bright. There are countless people that say it's a waste of time that will fade out soon (of course a lot of people said the same thing about computers ;) ), but there are others saying that it has some seriously untapped potential and advantages on future hardware. Personally, I also think DS is superior, but there are just so many problems that come with not being a mainstream tecnique.

[Reedbeta]

starstutter said:

Idk about that really... SSAO requires the normal and world position in screen space (well, if you're not doing a purley depth based approach). In forward, these have to be re-constructed, in deffered shading, the info is already prepared and easy to access

If it needs the normal vector, then you're right, because that's not really available in a post-process with forward shading. However, the world position is not necessarily any easier to get at with deferred shading than it is with forward shading. In either case you have to look up the value stored in the depth buffer, and shoot a ray from the camera through the pixel to the desired depth. (You don't normally store the actual world position in the fat buffer, at least in my experience, because for a sizeable world it would require a 32-bit float per component, so 96 bits for a 3D vector, and that just makes the fat buffer way too fat. Worlds for which a 16-bit half float per component is sufficient are pretty small worlds.)

Quote

I could be wrong as well, but I would think that the scale and mathematics would stay the same, and be cheaper compared to forward shading because there is no extrmley expensive overdraw. The only problem I forsee is that there could be artifacts on the borders between objects.

The parallax and relief mapping techniques I'm aware of don't incur any extra overdraw relative to ordinary normal mapping. Overdraw is when you draw a poly on top of a poly that's already there; parallax and relief mapping are purely pixel shader techniques and don't add any extra polys (except possibly for silhouette fins in some versions).

Quote

it seems like you could treat fog and light beams (ect ect) in screen space as well.

Yes, but there is no barrier to doing this in forward shading as well.

Quote

Above you mentioned doing DS in multiple geometry passes. Is this what you were reffering to? A lot of the papers I've read claim you have to have some kind of DB color regognition to determine the materials of each object as a post process...

Well, if you want to apply different shading models to different surfaces, then yes, you would need to do that. But most people just use a single shading model for all surfaces in the scene (you mentioned that as a disadvantage in your original post).

There are ways you can get around this a little bit, though. If your fat buffer is 64 bits, and you're using 24 for color, 24 for normal, you have two extra 8-bit channels you can use to store additional information. You would probably use one of them for specularity, and the other could be a parameter to blend between two different lighting models (dielectric and conductive, for instance). I believe they did something like this in S.T.A.L.K.E.R., which uses deferred shading.

[starstutter]

Reedbeta said:

Overdraw is when you draw a poly on top of a poly that's already there;

That's what I was saying. I know that it doesn't have pixel overdraw, because it's just replacing different parts of the image.I was reffering to vertex overdraw. Relief mapping is very very expensive (on today's hardware) so any polygons that have relief mapping and cannot be seen waste a tremendous amount of power. I was saying that deffered shading could speed it up in the sense that it only applies to pixels that are seen.

[Reedbeta]

Oh, okay, sorry. I misunderstood what you were saying in the second post. However I think my point still stands, because deferred shading does not really protect you from overdraw during the first phase (the geometry phase, which is where relief and parallax mapping are done). The way to avoid overdraw in that phase is the same as when using forward shading: draw things from front to back, which takes advantage of early depth culling to avoid evaluating expensive shaders.

[Shirakana]

starstutter said:

- global illumination becomes somewhat trivial

?? I wonder how you can get global illumination using DS ? GI can be splitted in many sub-effect (AO, interreflection, self-shadowing, caustics...) and I think (but I may be wrong because I miss some deep DS knowledge) DS can't provide enough information for all. For example, some faces will be culled during the first DS pass (fat buffer construction) although you need them to calculate inter-reflections/color bleeding stuff.

If you reduce GI as AO and some direct shadowing, SSAO and other methods is ok using DS. But for full GI solution, it can't be done with DS. Or maybe there are some bright methods I don't know yet !

[starstutter]

Shirakana said:

?? I wonder how you can get global illumination using DS ?

That's what I stated about 2 posts in. That I had said GI by mistake. I was talking about taking samples for AO and short range illumination. The culling issue with light sources disappearing can be greatly compensated for by including an additional buffer (less precise) with reverse culling.

[JarkkoL]

Reedbeta said:

The way to avoid overdraw in that phase is the same as when using forward shading: draw things from front to back, which takes advantage of early depth culling to avoid evaluating expensive shaders.

The overdraw is usually minimized with z-pass and not by sorting. Anyway, there's overdraw problems with deferred shading because you have to process same pixel for each light source. It's quite bandwidth intensive to fetch all the uncompressed material data from G-buffer for every light source that is lighting a pixel.