annoying…
good night 
Yeah, 6 renderings per light is hefty. But I do not think that the cost grows as fast as scenes get more complex. That is the key.
Question, say we have a 200,000 polygon scene and a 2 million polygon scene. Is the cost of finding all the silouette edges and optimizing the shadow volumes 10 times greater for the 2 million polygon scene, or much more?
I am be pretty sure that the cost will grow only 10 times using shadow maps, because even if we have to render the scene 56 times for 8 lights, the only increase is in the number of polygons.
I am guessing that the cost will be greater than 10 times using volumes. This is because I doubt that the silouette edge finding algorithms are O(n) or better. Since I have not looked at optimized methods for finding silouette edges I admit I could be wrong.
Oh well, I’m reluctant to go into more detail because it seems this deserves its own topic 
I would tend to agree that I may be premature to declare Doom 3 the great last gasp for stencil shadows, because rendering the scene 56 times for 8 point-lights seems like its a little far off
Of course, doing 8 passes when you could be doing 1 seems like a problem too.
You may be able to only render the cube faces that contain parts of the scene you are rendering. You could also cache the shadow maps and only rerender the faces which have moving objects in them. Hmmm, lots of possibilities
Originally posted by Nakoruru:
I am guessing that the cost will be greater than 10 times using volumes.
The typical brute-force shadow volume algorithm (including extrusion in hardware by vertex programs, see for example the ATI papter) has a trivial O(n) edge detection. And the fill-rate will remain the same. Thus, such shadow volumes scale linearly with the number of scene polygons.
folker,
Thats good, because it is always good to have more than one solution to a problem. My first, naive, guesses are edge detection gave me an intuition that it was not linear. But after more thinking I guess it can be done with one test per edge. But I think the CPU should be doing something better with its time.
The problems I see remaining are how to do multiple lights in a single pass, and how to do it when you have hardware displacement mapping or pn-triangles, or any other type of hardware generated geometry.
I see shadow volumes requiring more fill rate and polygon throughput than shadow maps. But, shadow maps require much more memory and texture units. Maps just seem to be a more general solution, they just shadow whatever you draw to the frame buffer (as long as its not semi-transparent, I have not heard anyone talk about a semi-transparent solution for either type of shadow).
I am thinking that next generation hardware will be able to do shadow maps with enough precision and speed that they will become the favored solution, but thats just a guess
I have favored stencil for a while, but I can’t help but feel they are doomed (no pun intended ^_^)
Shadow maps are very nice for shadowing, but they don’t solve as many problems as stencil shadow volumes can, particularly with regard to volumetric effects.
For any technique where the volume of light is important (i.e., spotlights cutting through fog), or perhaps better worded, “the distance light travels through a scattering medium,” you will need to be able to extract the analytical shape to get a good answer. Deep shadow maps are an option for software renderers, but support isn’t quite there in hardware yet.
Originally posted by Nakoruru:
But after more thinking I guess it can be done with one test per edge. But I think the CPU should be doing something better with its time.
the technique folker refers to is entierly on the gpu, done in a simple and quite short vertexshader.
and you can even blur the shadows afterwards with image post processing (blur them 3d in imagespace according to relation of disance to occluder and to light). will see if i can get this working when i have a vpu…
and shadowvolumes mean 1 pass each light. possibly without stencilbuffer even (we have now 4 free buffers to draw into), and possibly we can encode them all some way into the final buffer to store say 8, or up to 32 shadows in a texture. them we could do the lighting in one pass again…
Originally posted by Nakoruru:
The problems I see remaining are how to do multiple lights in a single pass, and how to do it when you have hardware displacement mapping or pn-triangles, or any other type of hardware generated geometry.
i think with the remind to my post above, its all in hw, you know the answer to the dispmap and that…
I see shadow volumes requiring more fill rate and polygon throughput than shadow maps. But, shadow maps require much more memory and texture units. Maps just seem to be a more general solution, they just shadow whatever you draw to the frame buffer (as long as its not semi-transparent, I have not heard anyone talk about a semi-transparent solution for either type of shadow).
generic shadow maps require much more fillrate and 6 times the geometry processing if you want to have them nice. as long as you can’t directly render to a cubemap, no, shadowmaps are no generic solutions. and about the transparent thingies, for alphatested transparency, shadowmaps are bether, but for the rest, as shadowvolumes can solve analythical problems, shadowvolumes can help there possibly (together with a projective image of the geometry, dunno )
I am thinking that next generation hardware will be able to do shadow maps with enough precision and speed that they will become the favored solution, but thats just a guess
24passes on ever changing rendertargets + 1 pass for the lighting of those 8 lights = 25passes. shadowvolumes with one pass for shadowvolume and one for the lighting will be 16passes. and, as i told you, we can possibly encode the shadowvolumes of several lights into one texture (or simply bind say 8 shadowvolumetextures), then we have 8+1pass…
imho its much less stressing…
I have favored stencil for a while, but I can’t help but feel they are doomed (no pun intended ^_^)
i dont think they are doomed yet. they are the only realtime useful generic solution currently existing. but yes they get doomed, its called doom3…