Horde3D

Next-Generation Graphics Engine
It is currently 28.03.2024, 09:32

All times are UTC + 1 hour




Post new topic Reply to topic  [ 4 posts ] 
Author Message
 Post subject: Deferred Shadow Maps
PostPosted: 02.02.2009, 20:05 
Offline

Joined: 22.11.2007, 17:05
Posts: 707
Location: Boston, MA
http://www.ziggyware.com/readarticle.php?article_id=235

Seems to be a brand new technique, and it looks very promising to help reduce the complexity of material shaders, especially if you are already using a depth-prepass.

_________________
Tristam MacDonald - [swiftcoding]


Top
 Profile  
Reply with quote  
 Post subject: Re: Deferred Shadow Maps
PostPosted: 03.02.2009, 00:21 
Offline

Joined: 08.11.2006, 03:10
Posts: 384
Location: Australia
I only had a quick skim over it, but it seems to suffer from the same problem as many deferred techniques - limited G-Buffer space.
If a shadow occlusion term is stored in the G-Buffer *for each light* then you will quickly run out of places to store them, which limits the number of lights which can use shadows.

In situations where you only need 1 to ~4 shadow-casters at a time though, it looks like a great way to solve the shader-permutation problem.


Top
 Profile  
Reply with quote  
 Post subject: Re: Deferred Shadow Maps
PostPosted: 03.02.2009, 01:19 
Offline

Joined: 22.11.2007, 17:05
Posts: 707
Location: Boston, MA
DarkAngel wrote:
I only had a quick skim over it, but it seems to suffer from the same problem as many deferred techniques - limited G-Buffer space.
If a shadow occlusion term is stored in the G-Buffer *for each light* then you will quickly run out of places to store them, which limits the number of lights which can use shadows.

In situations where you only need 1 to ~4 shadow-casters at a time though, it looks like a great way to solve the shader-permutation problem.
I think the question becomes whether you truly need a separate shadow buffer per light - my inclination is that fairly decent shadowing could be implemented with a single shadow buffer for all lights. Basically just additively blend the shadow contribution into a single buffer, and use the final value as the opacity of the shadow at that pixel.

At that point, it becomes much closer to light pre-pass rendering, and the performance should be fairly decent.

_________________
Tristam MacDonald - [swiftcoding]


Top
 Profile  
Reply with quote  
 Post subject: Re: Deferred Shadow Maps
PostPosted: 03.02.2009, 09:00 
Offline
Engine Developer

Joined: 10.09.2006, 15:52
Posts: 1217
swiftcoder wrote:
Seems to be a brand new technique, and it looks very promising to help reduce the complexity of material shaders, especially if you are already using a depth-prepass.

It is not quite a new technique but nevertheless very useful for forward rendering. Crysis is also using it:
http://ati.amd.com/developer/gdc/2007/Mittring-Finding_NextGen_CryEngine2(Siggraph07).pdf


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 4 posts ] 

All times are UTC + 1 hour


Who is online

Users browsing this forum: No registered users and 12 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron
Powered by phpBB® Forum Software © phpBB Group