Search Unity

Awesome Realtime GI on desktops and consoles

November 5, 2015 in Games | 11 min. read
Topics covered
Share

Is this article helpful for you?

Thank you for your feedback!

We've teamed up with Alex Lovett again and built The Courtyard, a demo that puts the Precomputed Realtime GI features in Unity 5 to good use. He previously built the Shrine Arch-viz demo. This time, however, the goal was to build a demo aimed at game developers requiring realtime frame rates. Check out this video:

This content is hosted by a third party provider that does not allow video views without acceptance of Targeting Cookies. Please set your cookie preferences for Targeting Cookies to yes if you wish to view videos from these providers.

Alex built the demo in about 8 weeks using Unity 5.2 off the shelf without any additional packages from the Asset Store - everything was built from scratch.

There is no baked lighting in this scene

The demo relies on Precomputed Realtime GI and realtime lighting throughout. It has a full time-of-day cycle, emissive geometry, about 100 animated spotlights that come alive at night, as well as a number of floodlights on stands and an optional player flashlight. The time-of-day cycle uses an animated skybox that is synchronized with the sun in order to capture the subtle lighting changes. In the playable demo we are now making available to you (see below), a UI has been added that allows you to control all of these lighting features in-game. Here are a few shots from the scene at different times of day:

The scene was created to be especially demanding in terms of lighting. A significant part of it is lit only by bounced light, and when the sun has set it is lit almost entirely by bounced light.

The realtime GI system works by precomputing all of the possible paths that light can take between static objects in the scene. This makes it possible to tweak the lighting in realtime, without interruption, because the system already has all the information it needs to quickly calculate the consequences of lighting changes. However, this means that static objects should not be modified, because doing so would require precomputing all the paths again. Given this, it makes sense to author levels in stages: geometry then lighting (and then repeat if necessary). Haphazardly moving static geometry around and adjusting lighting at the same time will require many lighting builds. We are working on more progressive and interactive lighting workflows for Unity 5.x. More details on this will follow in a separate blog post.

Authoring for Realtime GI

The demo was built with desktop PCs and consoles in mind, see the blogpost on GI in Unity 5 covering the Transporter demo for Realtime GI use on mobile platforms.

The Realtime GI system in Unity 5 is powered by Geomerics Enlighten and is designed for use in games. All the lighting computations are performed asynchronously on CPU worker threads; because games are usually GPU bound, the extra CPU work has very little impact on overall framerate. Also, only the areas where the lighting has changed are recomputed.

The lighting latency in the game is dependent on the resolution chosen for the realtime indirect lightmaps. In this demo Alex set the resolution to be relatively low - in order to be responsive - but such that it still captures the desired lighting fidelity and subtleties in the indirectly lit areas.

The indirect lightmap resolution was:

  • One texel every two units (i.e. 0.5 texels per unit) in the central areas.
  • One texel every 10 units in dunes close to the central area.
  • One texel every 32 units in dunes in the outer areas.

In order to balance the resolutions, an overall baseline of 0.25 texels per unit was set on the scene. Then, multipliers were added using custom lightmap parameters to give some really nice lighting and a precompute time of just 15 minutes.

The following screenshots show a shaded overview of the scene, the Enlighten systems generated, the UV charting view (showing the resolution of the indirect lightmaps), the clusters (responsible for emitting bounce lighting), the bounced lighting, and the lighting directionality (used for lighting off axis geometry and specular):

Care was taken to provide good lightmapping UVs. In some cases they were carefully authored to make sure that the models perform well for both lighting builds and the runtime. One specific instance of this is the staircase model.

Staircases can be difficult to get right, since at large texel sizes a texel can cover more that a single step. This can cause lighting levels to vary unexpectedly between the steps. On the other hand, using many texels for the steps becomes expensive in terms of performance. The staircase used in this scene also had bevels, which can really throw off the unwrapping and packing for realtime GI and generate many unnecessary charts taking up texel space. The initial staircase design looked like this in realtime GI UV layout:

use_normals_4_texels_ptx

This takes up a 70x72 texel realtime lightmap. There are two problems with this layout. Firstly, it uses too many texels per step (4x4); secondly the bevels are split into separate charts that also take up a minimum of 4x4 texels. Why can each chart not just use 1 texel? Firstly, Enlighten is optimized to use 2x2 texel blocks when processing the textures in the runtime, so every chart must be at least 2x2 texels. Secondly, Enlighten includes a stitching feature where charts can be stitched together to allow smooth results on, for example, spheres and cylinders; this feature requires that a chart have separate directionality information at each edge. Directionality information is only stored on a per-block basis, so a stitchable chart will always need a minimum of 2x2 blocks - becoming a minimum of 4x4 texels. Since no stitching is needed for the staircase, 2x2 texel charts suffice.

We have introduced an option for this in the Object properties of the lighting panel:

params - Copy

The value can either be 4, which works well for stitching in a setting that uses directionality, or 2 which is more compact. Setting the minimum chart size option to 2 reduces the texel density significantly - now the model fits in a 44x46 texel realtime lightmap:

use_normals

The bevels are still taking up unnecessary chart space. This is somewhat unexpected as bevels and steps have been authored such that the bevel is part of the step in UV space. The image below shows the UV borders overlaid on the model. Notice how the bevels are integrated into the steps:

stairs_uv4

In the 2D view of the lightmapping UVs the bevels do not show up. This is because they have been collapsed into the step charts so they do not have any area in UV space. This is done to avoid that the lighting simulation takes the sloped bevels into account.

stairs_uv4
params
final
env_panel2
tod_1sec
November 5, 2015 in Games | 11 min. read

Is this article helpful for you?

Thank you for your feedback!

Topics covered