Page MenuHome

Physically based defaults for Eevee Bloom and Shutter

Authored by Lissanro Rayen (Dragon.Studio) on Jan 15 2019, 10:47 AM.



Some of Eevee's Bloom defaults are not very good for physically based rendering. This patches addresses this issue.

This picture shows one of the problems with current default. Bloom looks very foggy:

Even worse, light emitters much dimmer than the Sun can make everything equally hazy if Clamp is set to 1.0 and intensity to 0.8 (current default). Artists often forget to adjust Clamp value and do not know what value to use for realistic intensity. Also, currently both Clamp and Intensity do not have good UI ranges. This is why often Eevee renders end up very hazy and bloom often does not look right.

Bloom effect plays important role to help to distinguish between bright and relatively dim light sources. With current defaults this is broken because Clamp set to 1.0. Also, it cannot be disabled if set to 0 like expected. This patch fixes this and sets it to 0 by default. If users need to clamp, they can do so easily with UI range up to 1000. This range is good enough for most cases and provides enough precision to control lower values, and the highest value helps to limit bloom from the Sun if necessary and will leave untouched most other light emitters. If needed, much higher values for Clamp can be entered manually up to 100000. 10000 is still affects the Sun, but up to 100000 highest limit allows to clamp anything that is much brighter than the Sun if user needs to limit bloom in such cases (for example, bright explosion in the sky or anything else very bright).

I propose new default for bloom Intensity - 0.05 and UI range to suggests realistic values. Bloom Intensity > 0.1 is not realistic for clean lens but the user can enter manually much larger values if needed.

For comparison, here is a my own photo with and without bloom caused by the Sun (on second photo the Sun was occluded with an object).

In real life bloom is much more subtle and does not look hazy. If Clamp is disabled, then out of 0.1, 0.05 and 0.025 values I have tried, 0.05 looks most similar to the photo. Here is test render with and without bloom with the Sun in similar position like on the photo:

Using color probe 27x27 I compared lightness below the horizon under the Sun. In rendered by Eevee images lightness difference was 17. In case of the photos lightness difference in similar place was 11. I then compared leftmost spot (also below the horizon) and lightness difference was approximately 2 between two photos and 1 between rendered images. In other words, with these settings bloom effect is not too strong and is not too weak. Visually it may seem like decreasing bloom intensity may increase photorealism, but then bloom effect would be too localized even for the Sun.

Besides this single test, I tested in many other scenes as well, with and without the Sun, with different HDRIs, and as far as I can tell 0.05 intensity turned out to be good default - it produces bloom strong enough to be noticeable and not too hazy.

In Cycles shutter default value is 0.50, so for consistency set to 0.5 by default in Eevee too. Besides, 0.5 is typical standard for real cameras, and values higher than 0.5 usually are needed only if very strong motion blur is desired.

Here is summary of all changes:

Bloom Intensity: 0.8 > 0.05
Bloom Intensity UI range: 0-10 > 0-0.1
Bloom Clamp: 1.0 > 0.0 (disabled by default)
Bloom Clamp manual range: 0-1000 > 0-100000
Bloom Clamp UI range: 0-10 > 0-1000
Shutter: 1.0 > 0.5

This patch is related to the discussion in this thread, there are more examples of what bloom will look like with 0.05 intensity by me and others:

Diff Detail

rB Blender

Event Timeline

First of all, thank you for taking the time to search more sensible default values.

I agree with all the changes you propose. I'll merge once you fix the style and the missing default value.


Style : Curly bracket needs to be on the same line as the if.
Style : Space needed after if.


You forget to update the default value to 0.0

Thank you for reviewing the patch. I have fixed style issue and updated default bloom_clamp value to 0.0f.

Lissanro Rayen (Dragon.Studio) marked 2 inline comments as done.Jan 16 2019, 1:22 AM

Rando comment: For UI ranges controlling values which have no obvious unit or real life equivalent, should the convention be to have a slider between 0 and 1 in most cases? I ask because having something like Bloom intensity stop at 0.1 (even though the input allows higher numbers) would almost feel like a bug that someone would end up reporting. Why not scale accordingly and map ui 1.0 == 0.1 behind the scenes etc?

Why not scale accordingly and map ui 1.0 == 0.1 behind the scenes etc?

Because as its tooltip suggests it is "blend factor", it controls bloom color intensity. So if set to 0.05 bloom color intensity will be multiplied by 0.05 (in other words, reduced by 20 times). If it is not obvious, perhaps it should be PROP_PERCENTAGE? In this case it would look like this:

However if we use PROP_PERCENTAGE instead of PROP_FACTOR, this will cause compatibility issue: in all existing Eevee scenes which use Bloom, its intensity will be reduced by 100 times (for example, old file with bloom intensity 0.05 will have intensity 0.05%, 100 times smaller). Your proposal to scale internally intensity value by 10 will cause similar compatibility issue. Since we already in beta, I'm not sure if it is acceptable to break things like that.

Yes, you would have to implement a do_version converter if you went with my proposal to handle older files automatically. Maybe percentage makes more sense I guess? I'll leave it to you folks to make final determination; just sniffed weird at first glance :)

This revision is now accepted and ready to land.Jan 17 2019, 7:53 PM

I think it is fine as it is. It is like that in other realtime engines. Maybe @Pablo Vazquez (pablovazquez) or @William Reynish (billreynish) have an opinion on the UX of the blend slider.

This revision was automatically updated to reflect the committed changes.

I do prefer percentages (ie 50%) over factor controls (ie 0.5). With a percentage, it's implicit that it is an amount between none and full. A value of 50% is much clearer to the user than a value of 0.5. However, Blender is not very consistent on this currently.

And whenever we have a nodal input, percentages don't really work - unless we decide to just display all factors as percentages.