Deferred shading - Materials attributes

outlawhacker · 2008-03-15T19:24:36

Hello, I'm looking into deferred shading to light up my scenes and I have now come to the time where I want to use different materials for my objects. In a forward renderer, this is quite straight-forward since every object is shaded individually and I can just pass needed material parameters to the shader that is used. But when doing deferred shading it gets a little complicated how to transfer the material attributes into the light phase efficiently. I first thought of storing a material ID in a texture together with some variables used for the material and then do dynamic branching in the light shader. But this felt a bit ugly and I'm probably bound to run out of instructions sooner or later. And in my experience dynamic branching in pixel shaders is very costly. I read a previous topic on GameDev touching this subject: http://www.gamedev.net/community/forums/topic.asp?topic_id=396527&PageSize=25&WhichPage=1 AndyTX says here: Quote:As I mentioned, the branching is highly coherent and so the performance hit is minimal. He's talking about dynamic branching in the light shader, but what does it mean that the branching is "highly coherent" and why is this a minimal performance hit? Excuse me if I'm stupid here :P I also read about deferred shading in S.T.A.L.K.E.R. (in GPU Gems 2) and as I understand it they store their materials in a 3D texture and do texture lookups in the light shader. Andy TX about this: Quote:Furthermore another option (that I believe they used in STALKER) is to put your BRDFs into a 3D texture and use the material ID to choose the slice. This is a really easy, really high performance and quite flexable way of doing different materials without branching or multiple passes. Once again sorry if I'm stupid, but how exactly is this done without multiple passes? I guess that the BRDF parameters are the ones to use in my lighting calculation, and these change every time I change the lighting or change the objects position/orientation or camera position/angle. So isn't these parameters written to a texture during the geometry phase as with depth, normal and diffuse RGB? If so, I can only fit so much info in my textures - I'm on my 4th and final texture to use in MRT geometry pass (plus some free space in the other textures). When and how is this 3D texture holding material attributes filled and how does this eliminate the need for branching...? Thanks!

Graphics and GPU Programming Programming

Started by outlawhacker March 11, 2008 05:04 PM

29 comments, last by AndyTX 16 years, 1 month ago

AndyTX

807

March 15, 2008 07:24 PM

Quote:Original post by wolf
just try it at some point. Take a common graphics card that the target group of your game is using and throw a 3D texture on it :-)

Oh I definitely have and 3D textures are reasonably well handled on GF6/7 series cards and very well handled on G80 (as in, no slower than an equivalent 2D texture array or atlas, etc.). I'm not sure what sorts of tests that you've done, but the performance of 3D textures scales a lot more with access patterns than otherwise. Hell we even have several volume rendering applications at RapidMind that use 3D textures and are reasonably efficient.

Quote:Original post by wolf
Stalker: what was described in articles and what has shipped in Stalker must not have been the same thing. They had a very well scalable renderer that switched on and off a lot of features

Well obviously I'm not qualified to comment on how their shipping renderer works, but I'd be very surprised if they dropped the 3D texture idea or even scaled it. They heaped lots of praise for it in the GPU Gems 2 chapter, and the only real fallback would be dynamic branching or multipassing per material. Neither of the these would be reasonable on anything pre-G80, so I'd be surprised if they didn't just use the 3D texture BRDF as stated.

Quote:Original post by wolf
You want enough deltas in there to make lighting look good. Linearly interpolating the values does not give you enough variety. So you end up with a 3D volume texture that will be too big for the target hardware.

I'm not sure what you're trying to say here... the amount of "detail" that you can get from your BRDF texture is more related to its resolution than its precision. Even for resolution I can't see you needing any more than 256x256 per slice, and even that is probably overkill. I would also expect these textures to compress excellently as they are almost certainly quite continuous and smooth (you can't want discontinutities in your BRDFs!).

Deferred shading - Materials attributes

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Deferred shading - Materials attributes

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines