general shadow question


this might be very general, but I need an advice :wink: .

I have to implent shadows in my terrain engine. The terrain is rather large, about 2 x 2 km, and there is only one static light source (sun). Most objects in the scene are static as well (trees, buildimgs), but some are moving (car). The application is not running too fast, so it should not be the most expensive shadowing technique.

And I do not know very much about how to do shadows at all… I know how to do shadow mapping (in theory), and have hardly any idea what stencil shadows are. But I know that the size of the terrain will be a problem when using shadow maps.

And I do not have very much spare time to do excessive research work to find out what will be best, so I politely ask for an advice in which direction I should go on working.

The terrain is split up into segments (for example 10x10), so I thought of generating one static shadow map for each segment (with a reasonably high resolution) and have another one for each segment which gets rendered every frame and only contains the shadows of the moving objects, and then combining these in the final scene rendering stage. So I thought I would get high fps and also quite good quality as well. Or is this nonsense?

What do you think about perspective shadow mapping (;f=3;t=008198)?

So, finally, which is THE shadowing technique to go for in a program like mine?

Hardware is geforce fx.

Thanks for any advice.

As far as I can tell you don’t seem to be aiming to have dynamic lighting (by that I mean you don’t intend to have the sun moving). Perspective shadow maps are probably going to give you the best results (though I don’t know enough about them to know what their performance is like).

My 2c

I just finished implementing shadow mapping with my terrain demo. I tried using perspective shadow maps, but I had some difficulties. I may resume that effort again in the future…

Right now I have stuck with normal shadow mapping. I use an ortho projection for the light perspective. Currently I center the light over the intersecction of the terrain and the camera view. This provides decent coverage, but it is not perfect. There is some aliasing. Also, I currently have some self-shadowing issues on certain larger objects.

But overall, the benefit of having shadows on all objects really improves the sense of depth. It is well worth the effort in my opinion.

Good luck

That sounds like you have to render the shadow maps for each frame… wouldn’t it be better to have them pre-calculated? But then, I guess that having 100 (10 x 10) shadow maps with a reasonable resolution would simply need far too much memory.

Isn’t it in general that rendering techniques go in the direction of having less complex geometry, but more rendering passes (like doom3), so I should be aiming at that as well?

What about combining shadows with deferred shading? I guess, it is not posible to use shadow maps with this technique, and I am thinking about implementing this sometime in the future to be able to have a lot of light sources (like a night scene with street lights illumination everything).

Thanks for replying.

Yes- I do render a new shadow map each frame. I render all shadowcasting objects from the lights perspective into a pbuffer, and then render the entire scene from the camera perspective using the pbuffer as the depth texture. The downsides of this approach include aliasing, coverage, 2-passes, solid black shadows, etc…

I do think your approach of using a patch of static shadow maps would definitely work. I also think it would be faster - how much faster depends on alot of factors - especially how much static geometry you have. I think it is definitely worth your effort to explore further…don’t forget to post your results…


Good luck!


It sounds to me like all you need is precomputed lightmaps on static geometry and some form of drop shadows from the dynamic objects. Especially if you’re going to have night-time city lighting, where there will be dozens of lightsources illuminating everything.

Usually, when rendering open outside enviroments, you’ll need lots of polygons, so you propably shouldn’t compromise too many polygons for fancy shading.


At daylight, I would go for shadow maps, since the sun is a directional lightsource and you certainly want the alpha-textures of trees and such to cast shadows, and not only the trunks of the trees.

At night, or indoors, it’s another story, you may have many small point lights where stencil volumes are better because most lights are easily bound
with small scissor rectangles and they don’t require you to render a cubemap for each omnidirectional light.

But on the whole you have a scalability issue.

There was an interesting presentation by Tom Forsyth about taking shadows out of the demo into the real game (sry, no link handy). The main point is you need a system that deals with LOD, in the same manner that you have a terrain system that deals with LOD.

For a starter, think of you have 3 shadow maps, one covering the whole terrain at a low resolution, and a medium resolution and hight resolution map centered around where the viewer is. These may get updated infrequenty. Then each object or each chunk of terrain selects one of the shadow maps based on distance to the viewer.

I think it is an important decision whether the engine should be daylight only with one directional light source, or also enable night scenes with several point lights… So I guess I have to discuss this, but will likely to leave it daylight-only.

Thanks for all your help, it seems that shadow mapping with several static precomputed depth maps seems to be the easiest way, and also quite scalable. I will start with that, and after that, add dynamically generated shadow maps for the moving objects.

One issue is whether the shadows should only be visible on the ground (objects and ground casting shadows on the ground), or also on the objects and trees. But as I have to rework rendering of those anyway, I guess this will be possible, too.

I just did some calculations… assuming the terrain is 2000 meters x 2000 meters, and is split into 100 segments (10 x 10). Each segment should have its own precalculated shadow map.

With a shadow map size for each fragmet of 256x256 texels, the resulting 100 shadowmaps will take up a fairly large amount of graphics card memory (256x256x3 =196608 x 100 = ca. 18 mb), and as each segment will be 200 m x 200 x, each shadowmap texel is covers nearly one meter, which is obviously not sufficient at all. A shadowmap size of 512 x 512 will take up far too much memory and will still be not fine enough. Texture compression might help a bit but but certainly not to the amount that the shadow maps could be fine enough.

So I guess that this approach is not very reasonable. But what to do then? Use perspective shadow mapping? But this technique requires rendering the shadow maps each frame, right?


Redrawing a shadow map isn’t that slow, I’d give perspective shadow maps a shot. I’ve had some good results with the technique described here:;f=3;t=011338

Results (1024x1024 map):

An alternative would be sticking to static shadow maps, but instead of keeping them all in memory at once, only storing the ones that are visible and rendering new ones as they come into the view. But when combined with moving objects, this option gets much more complicated.


My newest idea is to have precomputed shadow maps with a rather low resolution (128x128) which are used only for the segments that are far enough away, and for the ones which are near to the viewer, draw high resolution maps each frame.

But as segments that are far away may also need updated shadow maps because some objects in the scene are moving, I might as well skip the approach with using precomputed maps.

With the technique you posted and with perspective shadow mapping you only need one shadow map, even for very large scenes, as the map gehts mapped to the viewport (more or less), right? So it seems like I have to bother with one of these techniques…

The image looks great, I want to have such a quality in my engine, too :slight_smile: .


Well, as you can see, my scene isn’t as big as yours, so I can’t say anything definite about huge scenes. But if it turns out you don’t get enough resolution, you can use low-res static maps for distant parts like you suggested. I wouldn’t worry about moving objects casting shadows there, nobody’ll notice if they’re missing.

The resolution is better close to the camera, and you can control the tradeoff between near and far quality by adjusting the n and f parameters mentioned in the document. An exception is the rather common case where the sun is either in view of behind it. In that case the technique degenerates into a traditional shadow map. If the visible part of the scene isn’t very deep in the direction of the light (for example light coming from above, no huge heigth differences), it’ll be ok, otherwise the resolution will get bad.


Thanks for your hints. Due to the matter of the application, uses will focus on the moving objects, so they casting shadows (and being shadowed) is one of the most importants aspects.

I think I will start with small precomputed shadow maps, it will be enough work to get them working. I just found out that to add them to the engine, I will have to rework nearly everything else… :frowning: .

Another question (sorry :wink: ):

The program uses a fragment program for drawing most parts of the scene. So do I have to compute the shadow thing with the fragment program (depth comparison, but I don’t know how to do a comparison with a fragment program at all, wouldn’t it have to have conditional parts?), or can I still use GL_DEPTH_TEXTURE (or whatever is right)?

Do I have to draw a separate pass for ambient light?