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.

Report RSS The Big News Pack 4/6

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 on

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!

Static/Dynamic Lighting

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.

Ambient occlusion

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.

AO Comparison


Okay... the next time "will" be the dragon in narrow spaces one... stupid capture software. Also included some "trigger-happiness" :P . Say tuned.


Will you have the static lighting be more blurred like it is in most games today or will they look just like the dynamic ones?

Reply Good karma Bad karma+1 vote
Dragonlord Author

The look essentially the same as they are done using the same shadow casting shader code but with the difference that they have been created only once. It is possible though the shadow maps can have different sizes (as static ones sticking in GPU cost memory). With a smaller resolution the shadows would be more blurred. But currently they are the same size.

The story will be different for pre-calculated lighting but that's something to come.

Reply Good karma+1 vote

I like your engine so far :D

and whats the optimal Polycount for models? ;3

Reply Good karma Bad karma+1 vote
Dragonlord Author

In general there is no limit or optimal value. The engine modules adjust the material thrown at them depending on the platform they run on. So if you go too high they can automatically down-scale your models. It's a good idea to provide LOD versions for this case as hand-made LODs tend to be nicer than automatic LODs but if they are missing it is better to auto-LOD than being slow. Potentially a module could also upscale your models it if too low for example using tessellation if available. So a reasonable middle ground is a good idea so that modules (and therefore indirectly the player) can scale up or down the way the want.

Reply Good karma+1 vote

Greath =)

Reply Good karma Bad karma+1 vote
Post a comment
Sign in or join with:

Only registered members can share their thoughts. So come on! Join the community today (totally free - or sign in with your social account on the right) and join in the conversation.

Follow Report Profile
Windows, Linux
Team Epsylon
Send Message
Release date
Engine watch
Related Engines
Drag[en]gine L-GPL
Related Groups
Indie Devs
Indie Devs Hobbies & Interests
Team Epsylon
Team Epsylon Developer & Publisher
Got it!

We have recently updated our privacy policy and terms of use in-line with GDPR requirements. More Info?