Performance tuning

Enlighten is very configurable through its input parameters for the precompute, and can scale to a wide range of quality settings and memory budgets. On the other hand, this also means that a bad choice of precompute parameters can result in poor performance. This page presents some background information on tuning precompute parameters for visual quality and performance, plus a list of the available precompute parameters that can be tuned.

The Enlighten calculation is executed asynchronously to the main render thread across several frames, or run with a fixed budget per frame, and can be tuned to have negligible impact on the per-frame render cost. There are several parameters, which affect performance mainly in relation to the size of the data generated by the precompute.

The runtime performance has a linear relation to the precompute data size, where less is faster. The most important two parameters in this respect are outputPixelSize and irradBudget. The first impacts the number of pixels in the output textures and therefore the number of pixels for which the radiosity computation has to be done. The second one relates to the number of form factors stored for each pixel. Here, a lower budget means that the computation for each pixel will be faster. Both parameters also influence the precompute time.

To minimize the precompute data size, choose appropriate radiosity properties and indirect lighting resolution for the scene. To reduce the number of lightmap pixels for complex meshes, use probe lighting or simplified lightmap UVs.

Another very important aspect is systems and system dependencies. If everything is in one system, or if each system depends on all other systems, then the precompute will be slow since it has to perform all the raytracing and so on against the entire scene. If the scene is split up into local groups of geometry, then the system dependencies can be set up to only connect neighbouring systems and thereby make the precompute much more local and faster. System dependencies are also important for the runtime performance. The less data you have to keep in memory to solve the radiosity for one system, the better.

There is no single golden rule for how large a system should be. You should try to keep to small units of data that work well with your streaming and job system. For example, you could choose to automatically or manually create systems to reach runtime data with an average size of 1-2 MB, where each system takes less than 1 second to solve. Additionally, each system can be precomputed on an independent node and solved on a independent thread. As always, there is a sweet spot granularity and associated overhead.

Another aspect that is critical for performance is to only trigger radiosity updates where you need them and/or limit the time you spent on radiosity updates based on some heuristic. It can help with bottlenecks to spend time optimising a scheduler for figuring out what to update, when, and how often. Especially in large scenes, you may not want to update the radiosity every frame, or even at all after loading the level. The actual radiosity update roundtrip time will depend on how fast your input lighting changes. If your level has constantly-changing atmospheric effects such as clouds, you may want to update the entire level within 5 seconds. For slower changes, such as real-time sun position, a round-trip time of five minutes might be fast enough.

It's sometimes desirable to unload the data required for dynamic updates (perhaps just for far-away systems) while leaving the far smaller lightmap data loaded: this allows you to have distant areas of a level that are still lit, but not dynamically updated.

It's important to experiment to determine the best scheme for your game and your integration.

Precompute parameters and their performance implications

For details of all parameters, see The precompute parameters. For information about tracking memory usage and resolving specific performance issues, see Technical troubleshooting.

Parameter	Guidelines
`outputPixelSize`	This directly controls the size of the output lightmaps. It is a linear parameter, so doubling `outputPixelSize` will result in an approximately fourfold increase in the number of output pixels. Enlighten memory and performance scale linearly with the number of output pixels. Because the Enlighten output textures contain only indirect light, good results can be obtained with extremely low pixel counts; indirect light is usually very low frequency in nature.
`clusterSize`	This controls the resolution at which Enlighten stores and can transfer input light. Like `outputPixelSize`, it is a linear parameter. Typically, it can be slightly larger than `outputPixelSize` without significantly reducing final quality, although this depends on the kinds of lighting environments you wish to use. Small, bright light sources will require a smaller cluster size for Enlighten to capture them accurately.
`irradBudget`	This controls the amount of data about its lighting environment Enlighten stores per pixel. As such, the generated Enlighten data scales close to linearly with this budget (but not perfectly, since there are other memory overheads). The higher the budget, the more detail there will be in the final indirect light output; however, Enlighten will take correspondingly more memory and computation time. A minimum budget of `32` generally produces acceptable results. `irradBudget` must be a multiple of `16`.
`viewVoxelMultiplier`	This parameter controls how aggressively Enlighten compresses the precomputed data. The recommended value is `4`; lower values usually result in high memory and execution time without a corresponding increase in quality.
`stitchingDistance`	This parameter controls the distances over which Enlighten tries to smooth out potential lighting seams. This smoothing process costs memory and time, so this value should be small; it is recommended that you set it to the same value as `outputPixelSize`.
`maxStitchingAngle`	This parameter controls the angular changes over which Enlighten tries to smooth out potential lighting seams. Again, the smoothing costs memory and time, so the value should be small - the default is `0.1` radians (`~5.7` degrees). Large values can result in large increases in memory and execution time, as they force Enlighten to smooth output across a large set of seams.
`edgeStitchingDistanceMultiplier`	This parameter controls the distances over which Enlighten tries to smooth out potential lighting seams. This smoothing process costs memory and time, so this value should be small, hence the default value `0.3`.