Shadow Techniques With Shaders

Shadow volumes is definately the way forward, since it can be so powerfully employed with shaders. Unfortunately, the technology will only really reach maturity with DX10.

The SDK tutorial on shadow volumes is quite good, but the technique employed is a bit of a mind bender. It involves processing the mesh at startup and, using the adjacency information, generating a pair of degenerate polys along EVERY adjoining edge.

These degenerate polys then become the sides of the shadow volume when extruded by the shader.

Shadow volumes are also detailed in the book 'Real Time Rendering Tricks and Techniques in DirectX' by Kelly Dempski, however, they cheekily use a torus mesh to avoid the requirement of the degenerate triangles.

Looking at the DirectX10 docs, the introduction of geometry shaders will do away with all the degenerate polys nonsense, since these can be produced on the fly.

I've decided to use fake shadows until then. :)

The shader is actually quite simple. Get the vector from the light to the object, then for each vert, do dot(lightVec,Normal) to determine if it is facing the light or not. If not, offset the position by some (large) factor multiplied by the light>object vector.

You also need to do several passes of any shadow casters. I didn't include my terrain simply because it became too costly in fps! This means the terrain can't shadow itself, boo hoo.

First, render the object as normal.

Second, render front facing polys (relative to the camera now) to the stencil buffer. If the stencil test fails, add 1 to the stencil buffer.

Third, render all rear facing polys, if the Stencil test fails, subtract 1 from the buffer.

Draw all other shadow casters in the same way, then finally draw a full screen aplha blended grey quad with the stencil buffer. This should only draw where the shadow remains.

Clear as mud?

Good Luck

Simon

EDIT: I amy have the pass/fail, add/subtract bit the wrong way round... from memory!

I've read a couple of papers over at DevMaster.net about stencil shadows, but still am unsure of how to implement it. I know there is a stencil shadow project in the DirectX SDK, but just reading code doesn't work well for me. Does anyone know of a tutorial (in similar fashion to NeHe) that would show me some C++ and HLSL code for doing stencil shadows with a decent explanation of what's going on? If not, I guess I'll try and learn from the DXSDK project.

I'm not sure if you'd want to spend money on a book or not; however, the ShaderX books are very nice for learning shaders and their techniques. In ShaderX2: Tips & Tricks with DirectX9, there is an entire section dedicated to shadows.

Check out Half.com if you don't want to pay full price for the book.

Quote:

Original post by sipickles Shadow volumes is definately the way forward, since it can be so powerfully employed with shaders. Unfortunately, the technology will only really reach maturity with DX10.

Every time a new technology pokes out, some propose this.
I would like to point out that the same advances with D3D10 also powers Shadow Maps quite a bit. I'm sure those advances look much more interesting with Volumes because of their simpler approach - suddendly, almost everything can be done on GPU. Unluckly, they still need one pass per light and unless you extend the method beyond the standard stencil buffer, this is a problem.

Although hobbyist programmers are very likely to have no problem from patent 5|-|1t, it should be at least mentioned that Carmack's reverse patent is actually held by Creative Labs, which had no problems enforcing it. If you code for fun that's a non-issue but if you have market as a long-term target, you're better think about it, at least as a exercise.
Some shadow mapping algorithms are also patented for the manner but there are a few which aren't (yet) and they look quite promising.
Sorry to be a little off-topic here.

Quote:

Original post by sipickles I was wondering which ones are personal favorites among developers.

As you may have understood, I'm a shadowmap fan. I've tried and I found they work great with powerful fragment processing. Although they're a bit more costly (and actually provides less quality than volumes IMHO) they scale well with the number of lights.

In case someone wants to know, yes, I realize that composing the shadowmap is actually a light pass but those passes takes less GPU power and I'm confident they could be parallelized as well using MRT. Doing the same with Volumes is probably less trivial than that.

IANAL, but I have published 'Carmack's Reverse' before either Carmack or Creative's invention date, as part of my 1999 GDC presentation on 'Using the Stencil Buffer'. This likely represents prior art, and thus makes the patent invalid.

It also could be argued that creative didn't patent ZFAIL shadow volumes, but ZPASS, GREATER shadow volumes, which are not the same thing, as they have very different perf characteristics.

I prefer shadow maps, but for some applications, shadow volumes have their uses. It really depends on the app.

My argument against shadow volumes as the be-all and end-all approach :

'Trees'...

Quote:

Original post by SimmerD IANAL, but I have published 'Carmack's Reverse' before either Carmack or Creative's invention date, as part of my 1999 GDC presentation on 'Using the Stencil Buffer'. This likely represents prior art, and thus makes the patent invalid.

For what it counts, Carmack's reverse (or your reverse) after all, just shoot the marching rays in the opposite direction. If this is "innovative", I wonder what is not.
I shall recall that there are SW patents which actually cite prior art but they're still granted.
Anyway, you just need to invalidate it.

Quote:

Original post by SimmerD It also could be argued that creative didn't patent ZFAIL shadow volumes, but ZPASS, GREATER shadow volumes, which are not the same thing, as they have very different perf characteristics.

I understand but looks like even ID had issues providing this information to lawyers - they don't speak our language, nor they read pseudo code!

Anyway, I read on Game Developer Magazine that many ISVs are getting interested in building a common prior art repository with legal status. If this would happen, it would be great but I fear it was just a proposal.