Version: 2019.1 (switch to 2018.3 or 2017.4)
LanguageEnglish
  • C#

DynamicGI.updateThreshold

Suggest a change

Success!

Thank you for helping us improve the quality of Unity Documentation. Although we cannot accept all submissions, we do read each suggested change from our users and will make updates where applicable.

Close

Submission failed

For some reason your suggested change could not be submitted. Please <a>try again</a> in a few minutes. And thank you for taking the time to help us improve the quality of Unity Documentation.

Close

Cancel

public static float updateThreshold;

Description

Threshold for limiting updates of realtime GI. The unit of measurement is "percentage intensity change".

Describes how much input lighting can change before the realtime lightmap is updated. When input lighting is updated, Enlighten keeps a running total of the difference in input lighting intensity since the last time lighting was solved. The current difference is added each update, so over time it is the sum of the differences since the last solve. Each update, Enlighten checks whether the running total of light intensity exceeds the previous result by a difference specified by the updateThreshold value as a percentage.

Lower values mean the realtime lightmap will be updated more frequently but will incur more CPU load. Higher values will result in it being updated less frequency, but will incur a lighter CPU load.

A value of 0 means that the realtime lightmap will update even on the smallest change in the input lighting. If the input lighting doesn't change, a value of 0 will not cause any updates to the lightmap. A positive value causes the Global Illumination to only update when the threshold is exceeded. This is useful for saving CPU cycles and updating those parts of the Scene where the lighting is being changed more frequently rather than other areas where the lighting is mostly static. The default value is 1%. Any positive value is fine but we recommend smaller values, as otherwise you might see popping artefacts (and incorrect radiosity).

There's no reason you can't go above 100% if you want to conserve more CPU cycles. The percentage is really the maximum error tolerance before a solve happens.

Any negative value will turn off temporal coherence, so the system will be solved every frame even if there is no change to the lighting.

Please note that higher intensity values get solved less frequently than lower ones, which makes sense as we perceive differences in low intensity lights more than in high intensity ones.

Did you find this page useful? Please give it a rating: