The Crussade for Shadows feature - Drag[en]gine Game Engine

   One straight answer ( which also is upheld by some here ) is light maps. In the old times of game development anything dynamic in terms of lighting had been a pain in the rear. Computers had been simply too weak and accelerated graphic boards still a luxary. A bright mind had the idea to simply prerender lights into a texture of low resolution and to blend it using multi-texturing. The low resolution did a good job on filtering. Cool so is thia already the solution? After all most of the lights in a scene are static with simply turning them on or off. Again the bill has been made without the bad guy, the shadows.

   Light maps have one huge disadvantage and this is that lights of various sources are grouped together. What is a bliss for speed is a nightmare once shadows are taken into consideration. If you have only one light source like the sun then this works out since you can use dynamic shadows and merge it with the shadow map. But why the hell do an extra waste of filtrate for a light map if you have generated a shadow map anyways? And if you have multiple lights you have no way of telling how to merge the dynamic shadows with the p recalculated shadows. In the Source Engine this works only because shadow casting is very fake. Hence shadows are nothing but a transparent overlay. This is obvious once two or more objects cast shadows on top of each other. Not only does one object not receive shadows but the shadow on the ground is doubled. If this is not a problem for your game all is well and you can go with this technique. But if you want to play with light and shadows and do things a bit more complex this is not an option at all. Besides deferred rendering hates light maps by nature. Getting them to work is a pain. So we need full dynamic shadow casting no matter what. But we have only a limited amount of filtrate and a nasty little Mini-Boss to fight with: incorrect lighting.

Lesson learned: Light maps worked in the past but they don't work anymore nowadays at least not if you look for dynamic lighting and complex lighting setups. In the worst case you trade fill rate of shadow maps with fill rate of creating light maps which is worse while loosing dynamic shadows altogether. If you run a deferred rendering system always go for pure dynamic lighting.

   Using dynamic shadow casting there are two major problems: unnatural lighting and over-lighting. Take first a look at the sample images below.

   In the left image a typical game scene is depicted with an engine using hard shadows. The resulting shadows are always black which is unnatural since in reality light bounces and lights up the shadows to some degree. The second image shows what happens if we try to cheat in some ambient term to light up the shadows. Suddenly parts of the scene is lit which should not be. This is a huge problem as this way a dark room next to a brightly lit one does not work. Neither solution pleased me for the Drag[en]gine so I went the hybrid way. The last image shows a combined shadow casting scenario where the scene geometry casts hard shadows preventing neighbor rooms from being lit improperly while still brightening up shadows of objects. Now this might sound like extra work since you need for this approach two shadow maps one way or the other. This is true but like always I have a plan and this plan was born using a test program.

Lesson learned: Ambient hacks are like the name suggests: hacks. They won't provide good results unless you work with only sunlight and no inside areas. It's worth investing time into a hybrid solution.

   So the question arises, „any ways of getting rid of slow cube maps so we can use efficiently this two-stage approach?" To test this I made a special test program I filled with complex geometry and actors to test point light solutions. Some interesting result emerged.

   Scaling the shadow map dropped framerate a lot for scene geometry but not so much for actors. In fact what happened is rather important for the upcoming optimization trick. Large triangles consume a lot of filtrate while rendering the shadow map as they touch a lot of pixels. Actors though composed of a lot of small triangles. Now recall the previous result of the combined shadow map with full shadow and penumbra shadow. Any way to combine that? In fact yes.

   I split up the triangles assigning them to different shadow maps. In fact all large triangles went into a low resolution cube shadow map and all object triangles went into a high resolution cube map. The speed gain had been impressive. Although I rendered two shadow cube maps, one at 512 and one at 2048 I spend not more time then rendering one 512 shadow cube map while retaining high quality for where it matters: the actors. Still there is one more trick. Why render the shadow cube for the scene geometry any frame? After all it stays the same as terrain meshes in the Drag[en]gine are forced to be static. So now the costly process of rendering large triangles to a cube map went away since the low resolution cube map was rendered once for each light entering the view frustum and discarded once it left for a long enough time span.

Lesson learned: It makes sense to think sometimes out of the box. Hybrid solutions can be very powerful. Try to exploit the strength of one algorithm and compensate the weakness with another.

   Going back to the Drag[en]gine with these interesting results improved the speed but not too much. 8 point lights with this setup on screen still dropped the framerate to 12 FPS while not doing yet smoothing on the shadows. That ain't gonna work. Cube maps dropped the frame rate brutally no matter how intelligent you use them. Hardware simply can't do them fast enough. We need something else.

Lesson learned: Cube shadow maps are no good solution for dynamic shadows. Avoid them whenever you can. No matter what tricks you play they are slow to create in real time and tapping into them is costly compared to a depth texture.