Enlighten Design Principles

Overview

Throughout the development of Enlighten we have endeavoured to choose the right trade-offs that give the best visual quality for the minimal performance impact. We believe that focusing on indirect diffuse radiosity from static geometry gives developers the single biggest uplift in visual quality with manageable runtime overhead.

This document describes some of the thinking that has gone into Enlighten, and attempts to explain some of the trade-offs and decisions that have shaped the APIs and the SDK.

Enlighten only simulates diffuse radiosity

Enlighten assumes that all surfaces bounce light diffusely. That is, that they emit light equally in all directions. There are various reasons for this:

• It allows Enlighten to run at interactive framerates.

• Radiosity is the one truly global effect within the subject of global illumination. Even only simulating diffuse light bouncing, you can still achieve a wide range of effects including colour bleeding, area lights, soft shadows and many others.

• It is possible to achieve specular-like effects using the Enlighten-generated lighting. This is the key to dealing with specular surfaces. Once the radiosity has been computed globally, this can be used to re-light specular objects locally, so that they appear shiny and correctly embedded in the world. The main approximation here is that the glossy surface is being modelled as a diffuse emitter for the purposes of radiosity, but in practice this is a good approximation.

In short, Enlighten is a radiosity solution that also supports convincing specular highlights from bounced specular lighting. It is therefore somewhere between a pure radiosity solution and a fully accurate global illumination solution, and focused on meeting the needs of game lighting.

Enlighten works with static geometry (but can re-light dynamic objects)

Enlighten incorporates a pre-compute stage, which means it simulates how light bounces from static geometry. The restriction to static geometry is not as significant as it might at first seem. It is still perfectly possible to incorporate forms of destruction within such a model. For example:

• The effects of a wall being destroyed can be realistically modelled by taking the outside world and projecting that onto the wall. Enlighten will then flood the room with light as if it flowed from the outside.

• When the number of states of the static geometry in the world is limited, one precompute can be performed for each state. This works well for "before" and "after" destruction.