Horde3D

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]

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]

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