Overview

The example code in the Low level runtime walkthrough assumes a scene with a single system. If there are multiple systems in a scene, the situation is more complicated because light can now transfer between systems.

Reading from multiple input lighting buffers

To account for the light transfer between systems, all of the relevant input lighting buffers are passed to each instantiation of a solver function (for example SolveIrradianceTask).

Internally, each system knows via its precomputed data which other systems to read from, and matches up the inputs using system GUIDs. This is a two stage process:

First, you must call the helper function Enlighten::PrepareInputLightingList to create a correctly ordered list from an unsorted list of input lighting buffers.
This list can then be passed to the solver function via the task structure. Note that the list could also be cached for use over several frames/solves. It does not matter if too many input lighting buffers are passed to Enlighten::PrepareInputLightingList - it silently ignores any it does not need to read from. The function also succeeds if there is a system missing; however, no light is transferred from missing systems, which may produce odd results. SolveIrradianceTask only fails with an error if the input buffer for the system it is trying to compute output for is missing.

Updating multiple systems

You must ensure that all of the required input lighting has been generated before starting to run any of the radiosity tasks.

To put it another way, the pseudo-code for updating multiple systems should look like this:

Loop over all the systems
- Update the input lighting for each system (see Providing input lighting).
Loop over all the systems for a second time
- Run SolveIrradianceTask for each system (see Solving for irradiance).
Solve as many probe tasks as required (see Solving for probe points). These can be run in parallel to SolveIrradianceTask.

The three loops can be individually parallelised, but the first loop must be complete before the others start - the solvers read input lighting from all of the systems.

Multi-threading

With a little bit of care, the Enlighten runtime can be parallelised very successfully. The key pitfall to avoid is updating input lighting for a system while it is being read by a Solve function. The simplest strategy for achieving this is to completely separate input lighting updates from solving updates, as in the pseudo-code above.

GeoRadiosity has a multi-threaded PC runtime. Enlighten uses Intel Threaded Building Blocks to run input lighting for several systems in parallel; afterwards, it runs radiosity solves for several systems in parallel. While all the threads are busy, the performance scales extemely well with the number of processors. Because the systems define the units of work, the best performance is achieved when the systems are all roughly the same size (and there are enough systems to occupy all of the available threads).