The Drag[en]gine is a fully customizable game engine and game development environment designed with modularity and extensibility in mind not requiring expensive licenses.
Lots of time passed with too many updates to fit in one news post so it has been broken into 6 weekly parts. Here is therefore part 4/6.
Posted by Dragonlord on Jul 3rd, 2010
GLC (capture software) has a little problem right now so I decided to change the order of the remaining news posts in the pack a bit. So this one is going to be a technical one while the next one will have some video and less text. Let's a go!
A couple of news posts ago I talked once about the dual-shadow mapping code in use by the engine to simulate better lighting conditions indoors. Rendering many shadow maps is though a strain on the GPU and slows down rendering a lot. Dynamic lights and therefore dynamic shadows are not required for all lights or all the time. To improve performance static/dynamic shadow maps have been added.
The idea is rather simple. Looking at a given light source there are usually two kinds of objects casting shadows: static and dynamic objects. Static objects do not alter their position, orientation, size nor their geometry. For such objects dynamic shadows would not be required since the shadows cast by them are the same for all rendered frames. On the other hand the dynamic objects alter at least one of these properties so their cast shadows change over time. Most games choose a light to be either static or dynamic rendering full shadow maps for the dynamic case or missing shadows in the static case. Both have their advantages and disadvantages. Therefore I chose a hybrid approach similar to the dual-shadow maps version I did before.
Light sources have now one or two shadow maps depending on their type. Dynamic lights always use one shadow map all objects are rendered into since these lights change their position so any kind of static shadow map is impossible. For static lights though two shadows maps are used. One shadow map is for static objects the other for dynamic objects. Objects are classified either static or dynamic with the ability to switch class at any time and as often as they want. The static shadow map is calculated once the light starts to affect the view frustum. It is then reused for all further frames until it stops affecting the view frustum. Furthermore a dynamic shadow map is calculated every frame with only the dynamic objects. During shadow casting both shadow maps are tapped and combined.
Why doing two shadow maps? Isn't this slow? The idea is simply and based upon timing measurements and other observations. Static objects are usually static map geometry or props not supposed to move. These tend to affect large spaces in a shadow map. Speed of shadow mapping depends largely on the amount of shadow map pixels affected/written. By rendering these large and static objects only once into a static shadow map a lot of render time can be saved. The dynamic shadow map is therefore only affected by smaller and fewer dynamic objects. This reduces the shadow map render time for the dynamic shadow map a lot. Tapping from 2 shadow maps is only marginally slower than tapping from 1 shadow map. As a test case I used a room lit with 11 light sources. Using this technique 11 light sources could still be rendered while without a similar performance occurred already with 6 light sources.
This is not the end though since the performance still has to improve more to meet my expectations. This will be achieved with static light maps for situations where lights are not required to cast dynamic shadows. Using this dual-shadow map technique though the amount of dynamic lights that can be rendered can be increased. Only downside is larger memory consumption. But for static shadow maps the resolution can be dropped by a notch to compensate if required.
A new texture property type has been added named „ambient.occlusion" . This property accepts a 1-component image defining the occlusion of a point on the surface. Ambient occlusion exists in different fashions and people tend to use it for the wrong effects. By definition ambient occlusion defines for each point on a surface the percentage it sees of a hemi-sphere around the point of interest aligned with the surface normal. The result is a value which can be used to darken points simulating how less diffuse light reaches points located in surface cavities. Due to this ambient occlusion is often brought in connection with sun light. Ambient occlusion can be used for this purpose but it's not the only purpose. In fact it can be also used for darkening other light sources. The graphic module supports now ambient occlusion for various light sources. In general all ambient light contributions are affected by this texture property. To avoid flat surfaces the ambient occlusion is also affected by normal maps.
Okay... the next time "will" be the dragon in narrow spaces one... stupid capture software. Also included some "trigger-happiness" :P . Say tuned.