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

An old wisdom states that the way is the goal. Nobody mentioned though what obstacles this way can have. Usually I do not write technical ( or like some people here call it „developer" ) articles but in this particular case I felt like this requires an exception. I went through quite some testing and playing around with different techniques to arrive at something which is a good ground to start with. Many of the results might also be interesting for others dealing with similar problems. So I wrapped this journey up in a little ( okay, a little large ) article. So let's start at the beginning.

Side note: All tests, results and images are done on an ATI Radeon 4870 512MB at a resolution of 1406x848. Target resolution is 1680x1050. The actual resolution is slightly less since the tests are made from inside the IGDE so some space is lost for the GUI controls. All images are preview size. Click on them for the full size. Some of them are 1406x848.

   To understand the problem first a little trivia about the default OpenGL module in the Drag[en]gine. In general there are two rendering approaches: forward and deferred.

   Forward simply renders each object with all lights influencing it in one ( or maybe multiple ) passes. This approach suffers from slowdowns and various lighting problems as soon as you try to make something complex or sophisticated. Many simple games use this method since it's faster to set up and works good for scenes of low complexity.

   The second one deferred rendering ( or some called it deferred shading but this is misleading as one will see later on in this article ) uses a two pass approach. In the first pass all geometry is rendered to buffers containing position, normal, diffuse, specular and other informations. Then in the second pass all the lighting can be done. This separation of producing geometry and lighting it is the main strength of this technique. In particular it doesn't matter how complex your scene is as lighting is always in screen space like a post processing filter. The render time scales now linearly with the geometry and light complexity instead of the multiplication of the two. This is used usually by complex games. This is also the technique used by the Drag[en]gine.

    Newcomers in engine development tend to see how nice this technique is by design and consider it the holy grail but the big awakening comes late. It's like comparing shooting with a pistol with shooting a rocket. The later one can do some big boom but if you don't aim properly you are toast instead. The main problem is that this technique promises lots of small lights at next to no cost and the benefit of using light volumes to reduce the lit pixels. But you made the bill without the evil guy.

   The main problem with lighting in deferred rendering is not the lighting itself but the shadow casting. While you can do tons of lights in such a system what is going to kill you is shadow casting. And this is where the high quality engines set themselves apart from the cheaper engines. Nobody wants to use one dynamic light and the rest is more or less static.

   A simple solution is to allow only spot lights. The advantage of this is that you can render just one shadow map and even scale it down at the distance to avoid wasting too much filtrate. But is lighting using spot lights enough? Unfortunately not. A scene with only spot lights is not only boring but causes a lot of additional problem. So we need point lights at one point or another. And while rendering spot lights is a problem with a relatively easy solution point lights are not. The main answer of engine designers in this case is „don't use them". People who know me know that I hate „don't use it". It's like using a cheat in a game when things get hard. So the goal had been clear: multiple point lights at reasonable speed at 1680x1050 resolution. But here comes the bad guy: shadows!

   In the Thief series shadows had been your friends but for deferred rendering it's the arch enemy. Rendering points lights itself would be cheap but calculating shadows is anything else but cheap. A quick approach is to use a cube shadow map. Obviously the main problem is that you have to render 6 spot lights to form a cube map. This can not be cheap and indeed it is not. One dynamic shadow cube map works relatively well but as soon as you crank up the numbers of them things get ugly. And playing at 10 or less FPS is simply not acceptable. Besides the quality is poor as this early shot from the Epsylon game shows:

   Not only slow but also rather pixelated. This shot features 3 point lights and the FPS rate had been already bad. So how can one achieve good framerates with tons of dynamic point lights? This requires quite some hacking around various edges. So it had been time to pack your sword to fight the monster... just how does one fight shadows?