Summary

With Unity 6 we introduce a new API for baking Light Probes. Baking no longer relies on the Lightmapping delegates, where the user gets callbacks during the baking process. Instead, the process is very explicit and free of side effects, enabling the user to control how many probes to bake at a time to balance execution time vs memory usage.

User Outcome

We expose a GPU backend focused on high performance and using OpenCL internally. A future backend will be able to use hardware accelerated ray tracing.

We use the APV probe baking editor code as the example for how to use the API. 

Documentation is available now: RadeonRaysContext, RadeonRaysProbeIntegrator and RadeonRaysProbePostProcessor.

Note that this API is only available for Light Probes and uses scene based input extraction. Lightmap support and support for procedural geometry is planned for a future release.

Summary

Baking lighting data is currently tied to the concept of GameObjects in scenes, which limits the Editor’s capabilities for scalable, modular & code-driven light baking workflows. 

Use Case / Intended Outcome

With the Light Baking Public C# API, we provide a robust, side-effect free, and supported C# API. This lets creators define the inputs that affect a GI bake (e.g. Meshes, Transforms, Materials, Lights etc) and the outputs to generate (e.g. lightmaps and/or light probes and their individual components like irradiance, directionality, occlusion, octahedral depth etc.). 

Additionally, several users will be able to use the API concurrently without state leaking through.

Some example use cases: 

• Create input data procedurally and use it in the API

• Extract baked sky occlusion data and use this data for your projects

• Write baked output directly to GPU memory, without touching disk

• Write baked output data to your own data structure

• Pass baked output data for further processing in a custom system

Summary

Unity already provides creators with realtime global illumination solutions through HDRP, like ray traced global illumination (RTGI) and screen space global illumination (SSGI). However, while these fulfill some of our creators’ use cases for achieving high quality lighting in their virtual environments, these solutions require high-end devices to run efficiently, so they don’t scale well across platforms. 

Use Case / Intended Outcome

With “Precomputed Realtime Global Illumination” we provide creators with a realtime global illumination solution that scales across a wider range of platforms than RTGI or SSGI. This “Precomputed Realtime Global Illumination” solution is based on pre-baked light probe data, which dynamically updates the indirect lighting on probe-lit objects at runtime, and enables creators to author, build and run realtime global illumination from dynamic lights off static contributors, like walls, ceilings, terrain, and static objects. 

Summary

The Scene is often used as a hub for collaboration, or as a method for managing the loading and unloading of data when streaming content. Projects often split content into many scenes for these reasons. Currently lighting data (the lighting data asset, light probe coefficients, lightmaps,  and reflection probes) is bidirectionally referenced to / from the scene file. This means that it quickly becomes challenging to manage unloading scenes while preserving lighting data which may still be needed by rendered objects in the Scene.

This limitation of the current architecture also means that there is currently no efficient workflow for including baked lighting data within prefabs This further limits the options when needing to additively load objects when in Play mode.

Use Case / Intended Outcome

With scene independent lighting data, creators will be able to use native Unity functionality to more easily manage how lighting data is stored and then loaded at runtime. For example, lighting data could be stored per-prefab, per volume or via a scene-agnostic lighting manager. 

By decoupling lighting data from the scene, lighting artists will be able to work in parallel with other disciplines with fewer interdependencies, which has the potential to unlock more effective authoring in team environments. We also see the possibilities for facilitating new game types by supporting procedurally generated levels with dynamically loaded content. 

Summary

It is hard to light realistic outdoor scenes containing dense foliage using dynamic time of day. The contribution of an animated sun and sky should be correctly attenuated.

Use Case / Intended Outcome

This feature bakes sky occlusion at authoring time into light probe volumes or per vertex, to then sample the occlusion values at runtime and use it to attenuate the sky lighting.

The use case is for creators to easily be able to set up outdoor scenes lit by animated sun and skies. 

Summary

Iterating on lighting data requires the entire scene to be rebaked to see changes. This is potentially very time consuming, especially in large scenes.

Use Case / Intended Outcome

With “baking only selected sets of objects”, users have the option to regenerate lighting for subsets of selected objects and light probe groups within the scene(s).

Summary

Using lightmaps on skinned meshes can be a viable alternative where using light probes does not provide satisfactory results. 

The problem is that currently skinned meshes are not supported for baking Lightmaps, example use case: skinned GameObjects that don't move around the scene very far, they simply play an idle animation. 

Use Case / Intended Outcome

This feature enables users to bake lighting data for skinned meshes.

Summary

Generating lightmap UVs for models at import means padding cannot be adjusted per-instance. Consequently we cannot guarantee instances will have sufficient lightmap padding to avoid leaking artifacts. Currently lightmaps are packed with significant waste, this impacts especially mobile users who build content for low-powered devices and rely on static lighting data.

Use Case / Intended Outcome

Artists should not need to worry about lightmap packing when building scenes. “Automatic overlap free UV packing with low waste “ supports unique per-instance lightmap UVs so each mesh instance can have chart padding adjusted, or be repacked in order to prevent overlap. Calculating pack margin is automatic and can accommodate any per-instance scaling / optimisation.

Summary

Presently there is no built-in functionality within Unity to support the queuing of bake jobs. Baking scenes is done manually within the editor, this makes the process of scheduling and/or baking multiple Scenes in larger projects cumbersome. 

Use Case / Intended Outcome

A “Light Baking Manager” allows users to create repeatable lighting "recipes" which can be baked individually, or in a scheduled way via a queue system. These baking jobs could be shared amongst development teams which would reduce the need for individuals to know the exact setup for a successful bake. Instead these jobs could be configured by a lighting artist, and shared through version control amongst all collaborators.

An extension to this feature is to be able to define and queue “bake jobs” distributed across remote devices and Continuous Integration systems. This means that lighting precomputation could be spread across multiple devices, reducing the time it takes for lighting data to build.

Summary

In some scenarios you may want to author lights that affect only indirect lighting of an area of your scene. 

Use Case / Intended Outcome

This feature enables you to create and place lights that are only seen by Lightmapper. 

An example use case is a cave, where sunlight penetrates through a hole in the ceiling and the sunlight bouncing off the floor does not emit strong enough lighting bounces. With “Bake lighting data with GI (indirect) only lights” you can choose to adjust the indirect component of the sunlight, so that it either emits more or less indirect lighting. 

Summary

With Tiled Baking, the process of denoising a lightmap is broken down into smaller ‘tiles’ with each tile being denoised one at a time. The tiles are then combined into the full lightmap to produce the final result. The data involved in baking and denoising large lightmaps (e.g., 4k lightmap resolutions) may not fit within the available. 

Use Case / Intended Outcome

For devices that are capable of running the Unity Editor, the Tiled Baking and OpenImage Denoising technique helps reduce the memory requirements of the Lightmapper. This technique breaks down the baking and denoising process into manageable chunks that can fit in the available memory at any time. As a result, you will be able to utilize Lightmapper to denoise any lightmap size with min spec devices of the Lightmapper.

Summary

This feature intends to solve two problems: 

1. Currently novice users are exposed to technical jargon like sample counts, and

2. Sampling of lightmap texels can be more efficient

For building lightmap texels, we currently use the same number of samples. However, some texels will converge more quickly so adding more samples here is wasted work, yielding slower bakes. For example, areas lit by direct light would require less samples than recessed areas lit primarily by indirect light.

Use Case / Intended Outcome

With “adaptive sampling of lightmap texels”, texels are sampled to the user's desired noise/quality threshold (Draft Quality, Medium Quality, Production Quality). Once this threshold is met, the sampling work is moved to other texels.

This way, bake times are accelerated, artist iteration times are increased, and novice users won’t need to be exposed to technical jargon like sample counts.

Summary

Updating light probe coefficients presently requires a complete scene rebake, including all lightmaps and reflection probes. This can be time consuming in large scenes.

Use Case / Intended Outcome

With “baking only selected bake stage(s)”, users have the option to update individual stages of a bake, such as regenerating light probes alone. 

Summary

Debug data, such as texel validity, light overlap etc is currently not serialized to the Unity project. This means that it cannot be saved for later, or shared in team environments. To rebuild this data users currently need to rebake the entire Scene, which can potentially mean multi-hour bakes and impact team productivity.

Use Case / Intended Outcome

With this feature, the lightmapper will write debug data to disk in a folder alongside lightmaps, so that these can be shared among the team, and versioned using VCS.