This section describes some technical problems that you may encounter when using Enlighten and how to resolve them.

Precompute

Problem	Reason / Solution
General	If you experience problems when using the Low level precompute API, call the `GeoAttachSystemLogger`/`GeoAttachLogger` functions to issue error or warning messages. For more information, please refer to the API documentation on Message Reporting and Error Handling.
Takes too long	There may be meshes that are unnecessarily included in the radiosity computation, or lightmapped meshes which could be more efficiently lit using probes. See Radiosity properties. The Indirect lighting resolution is excessively high. One or more lightmapped meshes requires an excessively large number of lightmap pixels. Use probe lighting if possible, or use simplified lightmap UVs to reduce the number of lightmap pixels. The scene contains one more more systems with an excessively large number of clusters. One or more systems has an excessively large set of radiosity dependencies.
Fails with an error message	Each error message should indicate the general problem and the part of the scene affected. If the cause is unclear, please contact Enlighten Support.
Crashes	Contact Enlighten Support, and provide the following files: If using HLBS, your exported Enlighten scene (excluding the __Build_<scene>__ folder) If using Low Level API, set the dump folder in the `IPrecompute` object and send all files that contain the word `Input` in the filename. Any `.dmp` files in the precompute folder.

Runtime

Problem	Reason / Solution
General	If you experience problems when using the low level runtime, call the `GeoAttachSystemLogger`/`GeoAttachLogger` functions to issue error or warning messages. For more information, please refer the API documentation on Message Reporting and Error Handling.
No indirect lighting	This occurs when no albedo data is provided to the runtime, or the albedo data is all zero. To rule this out, set the albedo to white This also occurs when no light sources are provided to the runtime. To rule this out, provide a white environment cubemap.
Unexpected random bright colours in output	This is usually caused by corrupt data being introduced and then propagated round the whole level by the Enlighten runtime. Running one Enlighten update only may help localise the initial problem. Ensure that all buffers are properly initialised (cleared) before running Enlighten. Ensure that all precomputed data is loaded into correctly-sized buffers and not overwritten. Ensure that all light parameters are sensible (do not contain infinite values, NaNs, or zeros for near/far planes etc.)
Laggy or jumpy indirect lighting updates.	Check that radiosity properties and indirect lighting resolution are configured to minimize cost. Check for problems with the way instances are grouped into Enlighten systems that could generate too many or two few systems. Check that the Enlighten probe regions cover only the areas where probes are required. Check that you provided updated lighting input to the high level runtime each frame.
Banding	The output texture(s) do not contain enough precision to capture a smooth lighting gradient (or, possibly, the precision is being lost later in the screen-space shader computation). Use a higher quality output texture format (for example, 16-bit floating point). If using a compressed output texture format, reduce the Enlighten output scale to increase the precision for low light levels (also adding a compensating scale factor in the final shader). The trade-off is that the dynamic range of the output lighting will be reduced.
High memory usage	Check that radiosity properties and indirect lighting resolution are configured to minimize cost.