Radiosity dependencies

Enlighten computes radiosity for the instances, probes and cubemaps in the scene. The radiosity at a given location in the world is the combination of bounced light from many other surfaces. The Enlighten precompute must decide the proportion of light received at that location from each cluster in the world. This produces radiosity form factors for the location.

The time required to compute these form factors increases with the size of the world. Significant time is saved by excluding radiosity systems that are occluded, or those that are so far away that they would have no significant effect on the lighting. The precompute automatically detects and culls unimportant radiosity systems based on visibility and distance.

For a small world, the time taken to perform this culling is much less than the time saved. In a very large world, the time to perform this culling can become very large. To address this, explicitly limit the radiosity dependencies that can be considered.

The set of radiosity dependencies defines the set of systems whose clusters are considered when computing form factors. When computing form factors for a given instance, clusters within the same system are always considered, therefore an instance always receives bounced light from all instances within its containing radiosity system.

Zone dependencies

By default, when computing form factors for instances, probes and cubemaps, radiosity dependencies are not limited. To explicitly limit the dependencies of all instances, probe regions and cubemaps in a given zone, specify a limited set of dependencies for the zone.

To do this, output a .deps file in the same folder as the .scene file. Add a zone element with the name of a zone in the .scene file. Add a dependsOn child element with an id attribute naming another zone to be considered when the precompute automatically detects dependencies.

Radiosity systems within the same zone are always considered, even when you add an empty zone element. For a given zone, when there is no corresponding zone element in the .deps file, radiosity dependencies are not limited.

<?xml version="1.0" encoding="utf-8"?>
<dependencies>
	<zone id="zone1">
		<dependsOn id="zone2"/>
	</zone>
	<zone id="zone2">
	</zone>
</dependencies>

The example above limits dependencies in the following ways:

• zone1's dependencies are limited to systems within zone1 and zone2.
• zone2's dependencies are limited to systems within zone2.
• zone3 is not listed; all radiosity systems in the world are considered as potential dependencies

Explicit system dependencies

When you use explicit system groups, to make a zone depend on an explicitly named system, specify the name of the system in the id attribute of the dependsOn element.

Limit the dependencies of a system in the same way as for a zone. Add a system element with the name of a system in the .scene file. Add a dependsOn child element with an id attribute naming the zone or system to depend on. Add the attribute auto="true" to automatically cull the dependency if it is unimportant.

A radiosity system always receives bounced light from itself. For a given explicit system group, when there is no corresponding system element in the .deps file, radiosity dependencies are not limited.

<?xml version="1.0" encoding="utf-8"?>
<dependencies>
	<zone id="zone1">
		<dependsOn id="system1" auto="true"/>
	</zone>
	<system id="system1">
		<dependsOn id="system2" auto="true"/>
		<dependsOn id="zone1"/>
	</system>
	<system id="system2">
	</system>
</dependencies>

The example above limits dependencies in the following ways:

• zone1's dependencies are limited to system1 and systems within zone1.
• system1's dependencies are limited to system2 and systems within zone1.
• system2 does not receive bounced light from any other radiosity system.
• system3 is not listed; all radiosity systems in the world are considered as potential dependencies.