Jump to content

  • Log In with Google      Sign In   
  • Create Account

Better (probably) alternative to Deferred Shading


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
2 replies to this topic

#1 rozz666   Members   -  Reputation: 613

Like
0Likes
Like

Posted 21 May 2009 - 09:39 PM

I was thinking about an alternative to Deferred Shading that supports transparency and came with this idea. I haven't tested it yet and I'm waiting on your opinions. Preparation: - create an R int32 (or uint32, I haven't used integer render targets yet) buffer, I call it LM-Buffer (Light Mask buffer) - attach the Z-buffer from your "main" framebuffer to LM-buffer Steps: - fill the Z-buffer for early outs - draw light volumes like you do in Deferred Shading using additive blending, giving each light R value = 1 << light_index - draw the scene like in Forward Rendering, looping thru all light and checking in the LM-buffer if each light is needed This method supports up to 32 lights assuming you use only 1 32 bit channel (you can use more). If you have different types of lights, you can just put them in ranges, e.g. 0 - 16 - spot lights with shadowmaps 16 - 24 - spot light without shadowmaps 24 - 31 - omni lights 32 - directional light The lights parameters could be passed using uniform arrays or textures. Using transparent materials is straightforward, because you don't have a G-Buffer with positions, normals, etc., but you don't have to switch states for each combination of lights. I'm still thinking about shadowsmaps. Texture arrays are an option, but I'm thinking about the limits. I'll try to test it ASAP, but have no time right now. What do you think about this idea?

Sponsor:

#2 Krypt0n   Crossbones+   -  Reputation: 2571

Like
0Likes
Like

Posted 21 May 2009 - 11:45 PM

I think light index buffers have been introduced first when NVidia launched it's geforce 6800.

I was excited about that idea as well when they first suggested it :), but sadly it wasn't as smooth running as I hoped to, flaws I found at that time were:

- it needs dynamic branching, that kinda slowed it all down a lot on 6800 (although I worked in proper granuliarty of quads, not pixel by pixel)
- you do the 'culling' of lights in shader, you waste quite a lot of time
- in the end, you still have the lights*shader complexity which was kinda resoluved with the deferred shading and light prepass ideas.

there are several papers on this:
e.g. http://lightindexed-deferredrender.googlecode.com/files/LightIndexedDeferredLighting1.1.pdf

also check out tech papers of naughty dogs' last game, they used that tech in some specialized way afaik.


#3 MJP   Moderators   -  Reputation: 11352

Like
0Likes
Like

Posted 22 May 2009 - 06:36 AM

Yeah Light-Index Deferred Rendering has been around a while now. Its major drawback is that you have to fetch light properties based on the result of a texture read, which means you're talking either a dependent texture read (slow) or indexing into constant registers (slow, and not supported in older pixel shader profiles).




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS