Gravity Knight Part 7: Real-Time Lighting vs. Baked Lightmaps.

Written by Tim on

Real-time lighting requires nearly no preparations for good looking results. But this comes at a relatively high price. To calculate high quality lights and shadows Unity needs to draw nearly twice the amount of geometry. The computing power of modern graphics hardware is very powerful on desktop or console platforms but differs greatly on mobile devices. When we tested early versions of Gravity Knight on various Android smartphones, it became clear that newer devices can handle real-time shadows with ease while older ones suffer frequent framerate drops.

In conclusion we tried to avoid real-time lighting as much as possible.

Baked Lightmaps

Baked lightmaps are precomputed and therefore affect the graphic performance much less than real-time lighting.

You can think of lightmaps as textures that contain light information instead of color. Areas on an object which are in shadow are saved as darker pixels and lit areas are saved as lighter colored pixels. Those textures are mapped directly on objects during runtime, which makes lightmaps just as costly as an additional texture.

Unity offers different options for precomputed lighting. We didn’t plan to use normal maps of any kind, so we decided to use the “non-directional” lightmapping method as it causes the least load on the graphics hardware. You can read more about this topic in Unity’s manual.

To use lightmaps effectively some guidelines should be met. The first thing you need is a set of valid unique texture coordinates (also called UVs). The models exported from Qubicle have relatively tightly packed UVs which work fine for lightmapping.

Secondly it comes in handy when the geometry is reduced to as few triangles as possible, as each triangle gets considered for light-baking and appears on the lightmap itself. In our case the walls and some other elements were stripped off their back-faces because those are never exposed to the player’s eye and therefore waste a lot of texture and lightmap space. This way we were able to save about 40% for a simple wall.

A limitation of lightmaps is the fact that all objects which should be considered for it must be marked as static. This disables any transformation of the object at run-time. Therefore we could only apply baked lightmaps to the environment. All animated objects like the knight needed to be excluded from this process.

Lighting Settings

Unfortunately generic lighting settings which work well with every project are impossible to give. We had to run several tests to get results which were good enough to meet our requirements.

It turned out that 30-40 texels per unit gave us shadows which were good enough on most objects. We turned off the compression on the lightmaps because otherwise visual artifacts like shifted colors became visible. Furthermore we changed the filter settings of the lightmap to give it a more pixelated look by using point filtering.