Read the discussion at delphi3d on this subject. There are some suggestions on how to reduce the need the tesselation, I for one am doing adaptive subdivision, which results in a relatively low polygon count while still maintaining a good mapping. Preliminary results seem quite promising to me, I definently wouldn’t count this technique out of question. I’ll post my demo once I get it done. Unfortunately I don’t have too much time to spend on this at the moment, so it’s going to take a while.
Originally posted by okapota: well, i never implemented shadow mapping, but looking at games like splinter-cell, or the ogre demo, it looks like it can be a very good method.
Although the lighting in Splinter Cell is dynamic, as far as I can remember there were no moving light sources. I don’t know if anyone’s mentioned this around here before, but this situation allows for another simple yet effective optimization:
Precalculate the shadow maps for all static lights and static geometry. You don’t have to touch these shadow maps ever again unless the light source moves.
To deal with moving objects, you create a second shadow map for every light, to which you only render these moving objects. When rendering the scene, you bind both the static and the dynamic shadow maps, and multiply the results of the two depth comparisons. This gives you the logical “or” of the two depth test results.
In complex but static environments, this can make your shadow map updates a lot simpler, because you only need to re-render moving objects. The downside of course is that you double your memory requirements for the shadow maps and burn an extra texture unit.
Yes, that’s one good way to do it. My idea was to have one map and keep track of moving objects in order to only update the parts of the shadow map that need to be updated. This way I think you can reach about the same performance for static lights as you would with projected shadow textures.
Does GF3 and up support shadow maps in hardware?
ARB_shadow and the rest?
Is it fast?
There is one demo that uses these extensions but it runs in software mode. However, I dont see any artifacts.
It uses
GL_SGIX_depth_texture
GL_SGIX_shadow
WGL_ARB_render_texture
WGL_NV_render_depth_texture
So this makes a good alternative to stencil shadows. Frankly, I hate SSV!
So this makes a good alternative to stencil shadows. Frankly, I hate SSV!
Many things.
First, if you ignore all those *_shadow extensions, and just do the depth calculations/comparisions yourself in a fragment program, you get to choose whether or not you want to cull the pixel. You don’t have to make that ambient pass over your scene, nor do you have to make a render pass for each light. Done correctly, shadow maps only need 1 + n rendering passes, where n is the number of lights. For each light, you have to have a pass to create the shadow map. And then, you can use the shadow maps all at once (given good enough hardware) directly in your fragment program).
Stencil volumes, on the other hand, need 2*n + 1 passes. You have to render an ambient light pass. Then, for each light, you have to render the shadow volumes plus a pass to actually do the lighting computations.
Shadow maps, from this standpoint, are just more efficient.
Yeah, but assuming you are on a nv20 based card, omni-directional lights burn up 2 texture stages (and thats when you use the distortion trick, and you have to tesselate your scene all to hell).
With the stencil buffer, you free up all 4 texture stages, so diffuse/specular lights can be rendered in one pass:
Stage 1. 3d atten texture
Stage 2. base texture
Stage 3. normal map
Stage 4. normalization map
If you do an omni-directional light using shadow maps, you only have 2 texture stages (because the other 2 were used up for shadowmap calcs), so you have to either a) substantially lower the quality of your lights, or b) render them in 2 passes, and you have to do some major tesselation to the scene.
In my oppinion, shadow maps are definately the future, as image based techniques are usually superior to geometry based techniques. But, it’s also my oppinion, assuming you want fully featured normalmap lighting, that you’ll need a r300+ to do them properly. Otherwise, I think shadow volumes are actually your best bet for nv20 based cards, if done right. But thats just my oppinion!