Baked lighting is deprecated and will be removed in a future release.

Overview

This section describes how lightmap baking is integrated into the HLBS.

It is assumed that you are familiar with the HLBS (High Level Build System).

Baking extensions to the HLBS

Lightmap baking extends the HLBS with the following build targets:

BakeOutputDirectTextures
BakeOutputIndirectTextures
BakeOutputAOTextures
BakeAllTextures (bakes all of the above in a single step)

It is assumed that the integration code handles the compositing. An example of a compositor is included with the GeoConvert sample application.

Following a successful bake, the outputs are available in:

__Build_<sceneName>__/baking/<lightsFile>

Example baked scene

Inputs:

Input albedo	Input emissive

Outputs:

AO	Direct lighting	Indirect lighting	Composite	Final result in GeoRadiosity

The alpha channel of Direct, Indirect and Composite textures contains information about pixel validity. A value of 0 in the alpha channel means the pixel is invalid, and a value of 1 means it is valid.

Defining an HLBS scene file for baking

To prepare a scene for baking, you must add the following tags to the HLBS .scene file:

lmName — Specifies the lightmap output target
lmType — Specifies the bake parameters for the output lightmap target

The bake parameter sets are specified in a separate file <sceneName>_default.bp (see the example scene file below). This file maps the instances to their respective lightmap outputs. One lightmap is generated per unique lmName/lmType pair. The mapping to lightmap targets is orthogonal to the mapping to Enlighten systems. A single lightmap target can have instances from multiple Enlighten systems, and instances from a single Enlighten system can be spread among several lightmap targets.

For more information about baking parameters, see Baking parameters.

Assigning a different lmType to two or more instances that are assigned the same target results in a different lightmap for each instance. To map instances to a single output lightmap, the lmName and lmType must be the same.

Example scene file

ubox.scene

<?xml version="1.0" encoding="utf-8"?>
<scene name="ubox" version="1">
	<instance name="ubox_left" systemId="2" paramSet="Interior" geometry="ubox_left" type="Radiosity" lmName="B" lmType="512x512" position="-1000.0 0.0 0.0" rotation="0.0 0.0 0.0 1.0" />
	<instance name="ubox_right" systemId="1" paramSet="Interior" geometry="ubox_right" type="Radiosity" lmName="A" lmType="512x512" position="1000.0 0.0 0.0" rotation="0.0 0.0 0.0 1.0" />
	<volume name="Box01" probesParamSet="Cull_L1">
		<resolution x="5" y="5" z="5" />
		<size x="929.905" y="1713.1" z="932.167" />
		<position x="-467.011" y="-956.056" z="36.7885" />
		<basis>
			<U x="1.0" y="0.0" z="0.0" />
			<V x="0.0" y="1.0" z="0.0" />
			<N x="0.0" y="0.0" z="1.0" />
		</basis>
	</volume>
</scene>

ubox_default.bp

<?xml version="1.0" encoding="utf-8"?>
<bakeParamsList version="1">
	<bakeParams name="512x512" resolution="512 512" packUVs="false"/>
</bakeParamsList>

Handling of lightmap UVs in the HLBS

To generate lightmaps, an appropriate UV stream is needed for the input instances that go into a lightmap target. The UV stream must meet the following criteria:

UVs must be in the range [0,1] and also have the same aspect ratio as the light map. For example, a lightmap with a width of 512 and a height of 1024 must have UVs in the range [0,0.5]x[0,1].
UVs for instances must be non-overlapping
Individual charts must be separated such that there is a border of at least one pixel around each chart
Charts must be scaled relative to each other such that they have the appropriate resolution

By default, the chart UVs in the input meshes are used as the lightmap UVs. If you want to specify an alternative UVs stream only for baking, create a IBakeInputGeometryUvs object for each geometry and place the serialised file in the geometry folder, with the same filename as the geometry but with a .bakeuvs extension.

An optional workflow model is to author overlapping UVs for each instance individually and then use the Enlighten packer to repack the instances in a lightmap target to a single UV stream that meets the above requirements. This can be enabled in the bake parameters file for the output lightmap target:

[...]
<bakeParams name="512x512" resolution="512 512" packUVs="true"/>
[...]

If you pass in different chart UVs to the low-level baking API than to the low-level precompute API, you must generate an object of the IBakeInputGeometryUvs class for each geometry in your scene. This file must have the same file name as the serialised IPrecompInputGeometry object, but with the extension changed to .buv.

Providing albedo and emissive inputs

To use albedo and emissive textures in baking, copy each texture to a RuntimeTexture object and save it to disk.

Add the albedoRendered="EnlightenSystems" attribute to the top of the .bp file you are using
Write out the textures to files named BakeTextures/<Albedo|Emissive><systemId><paramSet>.rt
Compute the BakeAllTextures target (or separate components).

If instead you want to provide albedo for each mesh/geometry, then this may require more work. Packing the output lightmaps with Enlighten results in a paradoxical situation; the albedo and emissive textures provided for each lightmap should be in lightmap UV space, which is not available until you have baked the scene. To resolve this, an extra build target CreateBakeUVs is provided to pack the UVs for the lightmaps. This step outputs a UV file for each target lightmap in the __Build_<sceneName>__/baking folder. These UVs can then be loaded and used to rasterise the albedo and emissive inputs for the lightmaps.

Thus, the precompute workflow is:

Compute the CreateBakeUVs target
Read back the generated UV streams
Rasterise the instances into albedo and emissive textures using the lightmap UV streams
Write out the textures to files named __Build_<sceneName>__/baking/<Albedo|Emissive><lmName><lmType>.tex
Compute the BakeAllTextures target (or separate components)

If you are not packing, simply skip stages 1 and 2 above.

Static set dressing instances

Instances can be tagged as Static Set Dressing (SSD) by setting the type tag of the instance entry in the .xml file (see the example scene file above). Static Set Dressing instances differ from dynamic objects in that they cast baked shadows into the target lightmaps and they affect the AO solution. They do not, however, receive direct lighting and they are not included in the radiosity computation. The SSD type is appropriate for smaller objects that would not otherwise greatly affect the radiosity calculations, resulting in a significantly faster precompute. During rendering they can be lit by probe lighting and GPU-generated direct lighting.

Backface handling

In real-time rendering, backfaces are often ignored for rendering for performance reasons. In contrast, one way to avoid shadow mapping artifacts is to render only backfaces for the shadow map render pass. To achieve consistent lighting, Enlighten allows you to specify how to treat backfaces in both direct and indirect light map baking. The controls for indirect light map baking are the same used for real-time indirect lighting.

Shadowface handling

For direct light baking, you can specify whether front-facing triangles, back-facing triangles or both are used for shadowing using the shadowFaces baking parameter attribute, or the shadowfaceBehaviourType material attribute. See shadowFaces on the Baking parameters page and shadowfaceBehaviourType in the .mats format reference.

Baked probe sets

Light probe data is available after a successful bake of a scene with probe sets. A file containing baked L1 spherical harmonics is available for each probe set defined in the .scene file. These L1 probes can then be interpolated and provide the indirect lighting for dynamic and SSD objects. The files can be found in __Build_<sceneName>__/baking/<lightsFile>/<probeSetName>.bpst files, which are serialised objects of the IBakeOutputProbeSet interface.

Additionally, a __Build_<sceneName>__/baking/<lightsFile>/Direct_<probeSetName>.bpst file is generated containing probes with the baked direct lighting. A composited file, called __Build_<sceneName>__/baking/<lightsFile>/Composite_<probeSetName>.bpst is generated as well, simply containing both the direct and indirect lighting, added together and weighted by the values specified in the lights file.