I have an ide to use a shadow map to generate the capping of shadow volumes.
The idea is to …
Render the view volume as a stencil update into the lights shadow map context
Generate the shadow map that describes the shadow seen from the light but using the stencil
generate the volume out of the shadow map which now describes the volume enclosed within the view volume. The generation now only uses near and far plane to cap the volume. The rest is managed by the stencil.
My question is. Has anyone used or had simillar thoughts ??
I want to know if anybody has done this before or simillar or if this is really a new technique ?
The algorithm for shadowvolume generation out of a shadow map is as follows.
Render the view volume box backside into the light shadowmap view. Set stencil value at redered pixel to 1. Make the box just little smaller than the actual view frustrum.
Save the z depth buffer as back shadow map
render the shadow object where stencil value is 1.
render front side view box and increment stencil values where view box values are drawn
clear image but leave stencil
render shadow object + view volume back side where stencil is greater than 1
render view box front side where stencil is 1
save this z-buffer image as front shadow map
traverse the imagemaps and generate geometry by using the inverse of the model and projection matrix.
Multiply the normal view matrix with the inverse and render the back and front shadow maps as shadow volumes using normal shadow volume stencil technique
The result is an automatic view volume shadow volume generated out of shadow maps. The shadow volumes are capped and shows no anomalies as the user goes into the shadow.
It seems elaborate & expensive for what you’re trying to do. The following assumes that I’d understood your objectives correctly.
The simple sounding part where you traverse the image maps and generate geometry may prove complex, and you have to consider that these caps may have to match geometry generated other ways and that will raise some ugly issues. Doing this with an image based approach wastes time and reduces accuracy, in addition to requiring multiple image readbacks to the system memory. Smaller readbacks would have reduced accuracy and detail. Larger readbacks would be slower both for readback and processing.
Just trying to stitch the caps to other geometry could require an expensive search, unless you are talking about generating more than just the caps for this.
Also, something like a point light source with no spotlight effect would be problematic requiring multiple shadow renderings.
Finally, for these algorithms the geometry is self capping, the big issue is the viewing frustum clipping against the lights and that is solved by Carmack’s reverse. With the reverse the big issue is the far plane capping distance (which I dont think is a big issue) and I don’t see how you can get a good far plane cap from your approach which ideally should cap against scene geometry to reduce pixel fill.
If I’ve missed something perhaps you could start by stating what the problem is you’re trying to solve and why your approach is better than others and maybe explain where I’ve gone wrong, I did struggle a bit trying to grok your approach.
Try to search “shadow volume reconstruction” at google, and you will find a similar algorithm invented by Micheal McCool. He does not use the stencil buffer to create the shadow volume and the cap, but uses the depth buffer alone.
McCool claims the construction of the shadow volume out of the depth buffer (your step 9) can be accelerated by the hardware; however I do not know how this can be done. If done in software, i assume this task might be very slow, and it could be the main drawback of your algorithm.
I have posted some screenshots of the algo. On my GForce3 and a 600 MHz PC i get 30 FPS with the demo. I have a suggestion to add this technique to HW and then it would clearly outperform any existing shadow algo.
The algo toady is implemented in software but could easily be implemented in HW using an OpenGL extension.
one problem i have with this (and with shadow volumes) is they feel hackish
eg ‘There can be one shadow map per object’
personally i prefer an aproach where everything is treated equal ie u dont say this objects gonna cast a shadow but where the whole scene casts shadows without any special treatment/setup eg shadowmaps (though im not a fan of these (point lights with 6 renderings no thanks )
The advantage with my approach is that you can get really accurate shadows and dynamics. The shadow volume approach gives an additive “shadow behaviour” that for static objects needs only to be computed once for each light source. This gives you a scene e.g. a town or a forest that can be renderd 200 FPS. In this environment objects can move and get high accurate shadows. You do not need to set any “receive shadow” attribute or “cast shadow”. You can treat the whole scene as shadow enabled. BUT you will get much more precision if you treat object as shadow receivers/casters.
The shadow volume approach is additive in a much more easier way than to cope with shadow maps. I can render a scene with 300 Objects and use culling to selct which objects and their shadows shall be rendered. I can use umbra/penumbra on my shadows and even add effects like shadow lightmaps to simulate radiosity. The shadow map approach samples the whole scene to generate a generic shadow resolution for the whole scene. Shadow volumes can cope with multiple lights and a much more “local” refresh approach.
The combination of shadow maps and shadow volumes gives you the ability to render curved surfaces or skinned models with accurate shadows.