Depth shadowmapping and other things

· by Steve · Read in about 4 min · (743 Words)

Ok, so the lighting and shadowing enhancements in Eihort are taking me a lot longer than I anticipated, due to a number of factors, including distractions from a number of areas including the OGRE web server, VS2005 SP1 issues, Xmas shopping and the like, but also due to things never being as simple as they should be 😉 Whilst you can see from the screenshot that self-shadowing with texture shadows is clearly working, there are all sorts of aspects that I’ve been considering which are often overlooked in the proof-of-concept demos of these sorts of things. I’m incorporating some techniques from Shader X4 again here to minimise or eliminate depth fighting (calculating a slope scale bias in the shadow receiver and a fuzzy depth comparison) , but right now it only works well with LiSPSM or Uniform Focused projection, because I’m using depth here in a post-projection unit cube which suffers heavily from loss of precision at the far end. Focussing reduces this significantly but it needs to be addressed another way to be more generic. I’m going to be doing it in scaled linear space instead to eliminate this (which is how the Shader X4 demo does it) - the issue being defining the space generically, since the demos of this are always designed very specifically so that the scaling factors meet the needs of the small scene they’re working with - something that won’t work ‘in the wild’.

I’ve enhanced our first-pass scene processing (the finding and queueing of visible objects) to build up more information about the scene so that the scale range can be calculated automatically. We already build up a bounding box which is used as part of the focus region calculation in the focussed projection types, now we’re also collecting near and far depth ranges of any visible objects, which we can use from the shadow caster pass to figure out how to scale everything. I just need to hook this information up into automatic shader parameter bindings.

This is where Ogre’s queued rendering system comes in really handy. As well as being able to do smart things like sorting for render state efficiency, transparency and other queueing effects, the fact that we know a bunch of information about the scene before we even start rendering any part of it can come in very handy, as it does here.

I’m also considering changing the shadow_caster_vertex_program, shadow_receiver_vertex_program and shadow_receiver_fragment_program hooks and replacing them all with a link to a separate material. What happens now is that in the standard shadow modes, any of these programs are merged into the standard shadow caster / receiver pass (and this might be a custom material in itself). This is fine, except that if you’re using a custom material to do clever things like the depth shadowmapping shown here, you actually need different programs depending on which particular effect you’re doing. Difference PCF modes for example - you might have a simple 4-tap version and a 12-tap rotated poisson disk version for high-end cards. Right now if your individual materials need special shaders to go with their objects, you can only specify one set of shadow programs. If this was a material link, you could use material schemes to provide several shadow techniques for you individual objects to match your general shadow materials.

The other reason is that it’s easier to differentiate between ‘regular’ shadow techniques and ‘custom material’ shadow tehcniques - the latter being those that, as receivers, instead of tying into the regular extra-pass texture shadow approach (post-modulative pass, or per-light additive pass) actually pull in texture shadows as part of their original render, thus being much more efficient. Taking the regular shadow material links out into a single material link feels tidier somehow. I could also get rid of the merging of those per-material shadow shaders into the primary shadow passes, which was always a bit black-magic - making this an explicit link to a complete material is more visible, I think.

So, lots to do and think about. Eihort won’t make the end of the year clearly, but it shouldn’t be too long a wait. I’d rather do this properly than rush it out anyway, since this is a really important aspect now that texture shadow techniques are far more dominant than stencil shadows on today’s hardware.

It’s Christmas eve anyway, so this is my last bit of work for a while. Have a good one everyone 😀