Unity 검색

Awesome realtime Global Illumination demo

2015년 11월 5일 게임 | 11 분 소요
다루는 주제

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:

이 콘텐츠는 Targeting Cookies 카테고리를 수락해야만 동영상을 시청할 수 있도록 허용하는 타사 제공업체에서 호스팅합니다. 이러한 제공업체의 비디오를 보려면 쿠키 환경 설정에서 Targeting Cookies 카테고리를 수락하시기 바랍니다.

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:


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:


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:


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.

2015년 11월 5일 게임 | 11 분 소요

Is this article helpful for you?

Thank you for your feedback!

다루는 주제