shadow masks

[JPulham]

I've been reading this PDF on CryEngine2:
http://delivery.acm.org/10.1145/1290000 ... EN=6184618
It mentions Shadow masks. From what I can tell, you render the shadow maps into a depth texture (as normal), then you render each lights area of influence into the stencil buffer. These pixels then get a value from 0->255 in screen space saying how much shadow they receive (soft shadows) and each light is stored in a different channel of an RGBA texture.

repeat this for N*4 lights, with N textures.

these textures are passed into the main shader which calculate the lighting from each light based on the mask texture. This means that you can skin entire areas that are in shadow etc.

does this/would this work. Is this about right?

[BlindSide]

We unwrapped the cube map into six shadow maps by separating the six cases with the
stencil buffer, similar we did for CSM. This way we transformed the point light source
problem to the projector light problem. That unified the code and resulted in less code to
maintain and optimize and less shader combinations.

Slightly unrelated, but heres another case where they use the stencil buffer. I thought I would never have to worry about it when delving into the world of shadow maps, but maybe I should look into it if it proved useful for the Crysis team. If I'm not mistaken they took the Carmack route and used a texture atlas here?

I looked at the Shadow Mask part, and the only part they mention the stencil buffer there is for optimization reasons:

By using the stencil buffer we were able to separate processing of the individual slices
and that simplified the pixel shader.

So in this case its not necessary. The shadow mask texture itself just looks like a screenspace shadow texture that uses a component for each light.

The remaining issues aliasing artifacts and physics interaction bothered our shader
programmer and he spent some extra hours finding a solution for this. This new method
used a static mesh like the one before. The mesh projection changed from a perspective
to a simple top down projection. The mesh is dragged around with the camera and the
offset is adjusted to get most of the mesh in front of the camera.

LOL, I had a laugh at this one. So first they went through the trouble of projecting the water mesh from the view point in camera space, then attentuating the edges, etc, etc. Then they threw all of this away and went for a simple "drag the water mesh around with the camera and try to get most if it in view" approach. I guess it just goes to show that the most obvious approaches usually end up being the most suitable.

The reason I found this amusing is because I've been using the latter approach and I've been thinking about doing something similar to the first technique for a while now, but I guess theres not much point to it.