Eevee needs to have physically based defaults

[LudvikKoutny]

Hi,

recently, I’ve been finding it concerning that one can typically easily spot Eevee renders by a specific, fake looking glowy look. I think for the most part, this is caused by Eevee defaults, which on some places, are quite far from physically based rendering. Since majority of Blender userbase are inexperienced users, most of them will have no idea that the default values are wrong, and will falsely trust them under impression that person who has set them up probably knew what he was doing. Users should be encouraged and aided to achieve good looking result by being provided by good looking defaults.

The biggest sin in this case are the glow defaults. They are set up in a way which makes everything glow, regardless of actual light source intensity. This has significantly negative impact on the resulting photorealism.

Here is a screenshot of 3 emissive planes with intensities of 5, 50 and 500 respectively using default glow values:

It’s pretty obvious something is very wrong there. You certainly don’t want 12 stops bright sun disc on HDRI map to create equal amount of glow as a turned on laptop screen.

Now, this is the very same scene with as close to proper values as I could get:

This is how it actually should look like. Since Eevee is at least somewhat PBR based, there should be clear relation between glow amount and light source intensity.

Therefore, I propose new, proper defaults changes for glow:

1. Intensity of 0.01 (could be internally scaled to be presented as default value of 1.0)
2. Disabled clamping. Right now, clamp value of 0 does not disable clamping. It should.

Another sinner is Motion Blur shutter value, defaulting to 1.0, which is known as shutter crime, making images appear like smeary dream. It should never ever be used. If Eevee shutter value has parity with Cycles, then 0.5 is the proper value, which is default for most of the cameras.

I am sure there are a few mores, but these are the worst offenders which should be adressed ASAP so that they don’t keep damaging users’ quality of artwork.

Furthermore, would it be possible to give glow inverse square falloff. The currently present one appears quite linear.

[ThinkingPolygons]

Sounds like a “paper cut”.

[kio]

No, I think it would make sense to have a collection of ideas to improve defaults across blender, paper cuts turned out too messy and not everything is really UI related…

On the topic, yes more sensible defaults are always appreciated.

[ArtStallion]

So true, I hope they fix this asap. Good call, pal! We need more people like you.

[Dragon.Studio]

If Eevee shutter value has parity with Cycles, then 0.5 is the proper value, which is default for most of the cameras.

Furthermore, would it be possible to give glow inverse square falloff. The currently present one appears quite linear.

Good points.

Intensity of 0.01 (could be internally scaled to be presented as default value of 1.0)

I agree that default intensity 0.8 is too strong, with sunny HDRI all shiny objects and characters “bloom” way too much. HDRIs without sun are also affected, for example with Studio HDRI in LookDev I also get too much bloom with 0.8 intensity. But I think 0.01 is too low.

For example, let’s see how bloom effect would look with Rustig Koppie HDRI. The character below (WIP but good enough for this test) has grey hide with roughness values within 0.2-0.8 range, average roughness around 0.4. So the hide is shiny, but not mirror-like and it is of dark grey color - it shouldn’t be so shiny that whole picture becomes hazy because of extreme “bloom”.

This is what I get with default Bloom settings (0.8 intensity). Bloom effect is too exaggerated.

With 0.1 intensity there is reasonable amount of bloom.

At 0.01 intensity there is no bloom at all (increasing clamping does not help). But since highlights are of bright white color on shiny grey hide, I expected some amount of bloom.

I have tested with multiple HDRIs, including Studio HDRI in LookDev mode, tried different objects and characters, and the my opinion remained the same - 0.8 too much but 0.01 is too little. This is why I think 0.1 intensity would be better default.

[LudvikKoutny]

You can’t generally expect much of a bloom on objects that don’t have very low roughness and are non metallic on top of that.

The thing is, this if for example square with emission of 1.0:

1.0 color intensity at default exposure level is still relatively dim, you can get that even on diffuse concrete wall in cloudy, overcast HDRI setting. And even raising the value from 0.01 to just 0.1, as on the picture above, makes intensity of 1.0 glow way, way too much. I’d say that 0.005 is about the ceiling of reasonable glow, when the Clamp is set at max.

That being said, after comparing with some other renderers which do bloom/glare postprocessing out of the box, 0.05 (5x more) seems like more appropriate value.

I’ve downloaded the same HDRI you’ve used, and this is how the sun disc looks directly:

It looks more or less right at 0.05.

Metallic material reflection look appropriate too:

And even with non metallic materials, you’ll get some glow at 0.05:

But I encourage you to get any digital camera, even a phone camera, and take a picture of a dark gray polished but not shiny leather material, similar to one on your renders, during a sunny day with reasonable exposure value similar to your renders. I can guarantee you any glow will be hard to notice if the material is similar enough.

Even on sunny day, things don’t glow that much unless they are metallic or really polished (very low roughness):

[Dragon.Studio]

after comparing with some other renderers which do bloom/glare postprocessing out of the box, 0.05 (5x more) seems like more appropriate value

0.05 is acceptable value too. I have tried it and it looks good in all scenes I have tried so far. At least if clamping is set to 1000.

I decided to test what happens if I truly disable clamping in effect_bloom_frag.glsl by adding “if(clampIntensity > 0.0) {” in appropriate place in the code, and then by setting it to 0 in Blender I can disable it. And here are the results:

Intensity: 0.05, Clamping: 1000. Looking at the Sun. Reasonable bloom.

Intensity: 0.05, Clamping: 0 (disabled). Is it too much?

0.005 is about the ceiling of reasonable glow, when the Clamp is set at max

Intensity: 0.005, Clamping: 0 (disabled). Looks like intensity 0.05 with clamping set to 1000.

Intensity: 0.05, Clamping: 0 (disabled). I can see reasonable amount of bloom.

Intensity: 0.005, Clamping: 0 (disabled). No bloom at all.

Metallic Suzanne (the same material you have used). Intensity: 0.005, Clamping: 0 (disabled). Almost no bloom.

Intensity: 0.05, Clamping: 0 (disabled). Reasonable amount of bloom.

So what do you think should happen when clamping set to 0? Should it be truly disabled or set to max (clamped to 1000)?

[LudvikKoutny]

Yes, my results are probably messed up since even clamping of 1000 is apparently not enough to cover intensity a sun disc on a HDRI map. Given these results, I’d say disabled clamping and intensity of 0.01 to 0.05 would be a good set of defaults. But since I personally don’t know how to turn off the clamping in the manner you did, I can’t do the tests myself. I personally would not mind if the sun disc emitted even more glow on 0.05 than on my examples.

Generally, photographing the sun disc directly is almost impossible unless you go really low on EV, because of just how strong it is, so lots of glow is expected.

I just want clear, physical relation between glow amount and light source intensity, without any under the hood clamping weirdness. Clamping at 0 should really disable the clamping, and any sort of clamping on post processing effects should not happen without user explicitly choosing to do so.

[Dragon.Studio]

Just to be sure that 0.05 Intensity is a good choice, I also have tried 0.1 and 0.025 intensities with completely disabled clamping, and they gave me either too much bloom (too obvious white haze when looking at the Sun) or not enough (when looking at shiny objects without the Sun directly visible). So yes, 0.05 Intensity seems like a good starting point. I have tried with different objects and characters, and have used multiple HDRIs to check if this actually works well in different lighting scenarios.

In the past I did some photos with the Sun in the background, with same shutter speed and ISO, and with the Sun visible and occluded. I did this to research how much bloom the Sun should cause when visible. For example, here are two photos (f/5.6, 1/500s, ISO 80), they both were taken within interval of 8 seconds.

When the Sun directly visible, boom effect is so strong that even left bottom corner is slightly brighter. White rectangle was originally transparent (because I deleted part of the picture covered with object I used to block the Sun).

For comparison, here are two images rendered in Eevee. Sun position, horizon level and horizontal field of view almost match photos above (HDRI I have used). First image with bloom enabled (Intensity 0.05 and Clamp 0) and another one has it disabled.

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.

Eevee’s bloom isn’t exactly photorealistic, it just relatively simple approximation of real effect, so it is not perfect. But with new settings it is much closer to realistic bloom effect. For comparison here is the same picture with current default settings (0.8 Intensity and Clamp 1.0):

Another issue is that Clamp currently limited to 1000. This is not enough, at very least it should allow the Sun to remain unclipped but clamp bloom for light sources brighter than the Sun (for example, bright explosion). For Sun even 10000 is not enough, so I think upper limit for clamp should be 100000.

In the UI current range for Clamp seems too small (up to 10). I think it needs to be increased by two order of magnitude too (up to 1000). This allows the user quickly limit bloom from the Sun if needed, and also this range good enough to clamp bloom in relatively dark scenes as well. If needed, manually user will be enter values greater than 1000 (up to 100000) for Clamp.

I have created a patch to update Eevee’s Bloom and Shutter defaults (if nobody objects, I plan after few days to send the patch for review). Summary of 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

[LudvikKoutny]

Thank you for taking the time to make the patch. By the way, when you said that on your photo tests, the bloom was so strong that when the sun was visible, even the corner far from sun spot in the picture was brigther, that relates to another bloom setting, the radius. If you increase radius value from the default one, even just slightly, you should be able to get bloom to spread out far enough on your image it should actually cover even far corner slightly, like in the actual photo.

Of course I can understand reasoning for both defaulting to smaller radius value as well as higher threshold value to generate bloom from. Both of these are somewhat necessary to get good performance out of the box. Luckily, the important values we care about - the clamp and the intensity are not that much related to performance.

[smilebags]

Coming at this from a photography perspective, I think the amount of bloom for realism** is still likely to be too much for many cameras. Anything which isn’t at least 4 stops (16 times) brighter than middle grey shouldn’t really produce any noticable glare. In my opinion (which seems to be in line with Rawalanche’s) bloom should be used for conveying context and meaning to bright lights, making it possible to visually differentiate a light which is 100x brighter than middle grey from one which is 100,000x.

I understand that the intent of Eevee glow might not be to make something look like reality, but I feel like even 0.05 could be too strong for cameras other than oily mobile phone cameras. It is certainly better than it was, but I feel like this could get another review, potentially alongside convolution based glow (which allows for much larger and more complex glows with good performance) if it is introduced in a later 2.8x version. (It is happening here in Unreal Engine: https://www.youtube.com/watch?v=SkJgopq-JQA)

[rontarrant]

IMHO, every part of Blender should have reasonable defaults. And those defaults should be decided by some of our top user/experts in whichever area we’re talking about (for instance, Cycles render defaults should be decided by someone like Gleb Alexandrov).

[LudvikKoutny]

@rontarrant

for instance, Cycles render defaults should be decided by someone like Gleb Alexandrov

That was a good one…

Seriously though, it’s a bit more complicated than that. Gleb is just an artist, albeit a talented one. Despite that, Cycles defaults should be decided by Brecht. Especially those concerning things like performance, utilization, bias or memory management. In all those fields, Brecht’s knowledge is superior.

I am sure Clement (Eevee developer), also knows what he’s doing. The odd defaults for bloom in Eevee are likely consequence of either leftover defaults for debugging purposes (so that the effect glow is always clearly visible) or concerns that if the bloom defaults to physically plausible settings, some users could be under impression it doesn’t work, if they enable it in scenes with only faintly luminous surfaces.

I am trying to dispute that here in this thread, since I believe that physically based photorealism has priority over catering to unrealistic expectations of completely new users, but I would never imply that defaults, in general, should be decided exclusively by users, especially ones who focus on artistic side of the craft at the expense of technical understanding, like it’s the case with Gleb.

[Dragon.Studio]

I understand that the intent of Eevee glow might not be to make something look like reality, but I feel like even 0.05 could be too strong for cameras other than oily mobile phone cameras

Eevee’s Bloom indeed has “oily” look, especially on darker background but this has nothing to do with its intensity. For example, take a look at these pictures. First row - real photos, second row - Eevee.


Photos where taken at the same ISO setting but brighter photo had 5 times longer exposure. With darker background Eevee’s bloom looks like photo taken with oily lens, but that’s limitation of current implementation. Bloom Intensity in this case was 0.05 but this is completely irrelevant, it is the result what matters - what we get after “combining” bloom intensity and brightness of the light source(s). If we decrease either bloom intensity or make lights dimmer, then in brighter render we start to see individual “LEDs” and overall bloom will become too localized and then rendered bloom will not match real photo at all.

The same is true when trying to find intensity value for bloom based on photos with light sources of known brightness such as the Sun in order to make bloom as similar to real camera as possible. Too little and it will look less like on photo, too much and it will be too hazy, but either way it will not look exactly like on photo because current implementation is relatively simple. Anyway, default intensity value is just starting point. If you think some other value could be better starting point, please let me know.

bloom should be used for conveying context and meaning to bright lights, making it possible to visually differentiate a light which is 100x brighter than middle grey from one which is 100,000x.

With current default Eevee’s settings glow would be the same in both cases. And this is not only issue - even if you type in maximum value in Clamp field to get proper bloom, it was too limited for bright light sources such as the Sun. I have addressed these issues in my patch as well.

I feel like this could get another review, potentially alongside convolution based glow (which allows for much larger and more complex glows with good performance)

Yes, it is possible to achieve more realistic results with better implementation. For example, in paper «Physically-Based Real-Time
Lens Flare Rendering» was described a method to render in real-time very realistic lens flare. Authors even said that their algorithm could be used as a tool to recover parameters of unknown optical systems. This implies very realistic simulation.

[smilebags]

Interesting to see your photo and Eevee comparison above, that indeed gives some good context for what a sensible default might be.

I understand the speed tradeoff in this implementation is to do with the blur radius, and (potentially?) the cutoff, though having a ‘cutoff’ at all immediately stood out to me as too fake and likely to be covering up other issues (which have been found in this thread).

I believe your defaults are suitable for the current implementation at this point, I guess if people want the images to have the blur of a high-quality DSLR (which is very little) they can do it themselves with the settings.

That’s a great research paper you mentioned, too. It could be worth looking in to but I feel an image based convolution might be more approachable for both artists and developers. It doesn’t take into account position on the sensor/lens but lens flare and bloom/glow shouldn’t be confused anyway.

Thanks for your patch and I look forward to trying it out.

[FredericoMartins]

yeah starting with the default theme!

[LudvikKoutny]

I’ve found this great example on Facebook today:
https://www.artstation.com/artwork/rRlbOG?fbclid=IwAR0-7V0TnqH3h0l0-zvGkXCfLmK-TdGT4T9ZWynyd87abYRyXQ3mmJpy5eg

This is how almost every typical Eevee render looks like, very glowy, blurry and hazy. You can clearly tell the guy is very talented artist yet his resulting image suffers from the very poor Eevee defaults. It’s just so easy to spot Eevee renders by that

[LudvikKoutny]

Any news on this? I just checked today’s build and the poor bloom defaults are still present.

[Dragon.Studio]

I sent the patch for review: https://developer.blender.org/D4212 . In Revision Contents > History > Created you can see that the patch was uploaded yesterday, but only today I have finished its description and sent it for review. The reason why I did not sent it right away, is because I wanted to use for a while new defaults and new UI and manual input ranges to make sure I encounter no unexpected issues and feel no need to change them.

[LudvikKoutny]

Alright, great! Hopefully it’ll get accepted. If not, I’ll start making some waves