EEVEE Bloom implementation issue

Archive Blender Development
1

Hi,

It’s not really a bug, so I assume this is the right place to talk about this.

I was studying the EEVEE bloom effect because it is gorgeous, but it seems that there is a divergence with the KinoBloom implementation it is based on (which is probably based on the method explained here).

During the upsampling phase, KinoBloom will blur the previously downsampled/upsampled texture (last bound here, which is MainTex here).

In Blender, it will bind the source at source/blender/draw/engines/eevee/eevee_bloom.c:326 and blur at source/blender/draw/engines/eevee/shaders/effect_bloom_frag.glsl:190. If I’m not mistaken, it is adding the upsampled data with the blured previously downsampled buffer at the same step (the same size, not an upsampling).

Is it intended ? I wonder if it looks better in any case.

Also, by doing the blur in chain, we only need one texture of each size for the downsampling and upsampling phases (downsample blur to N-1 texture -> N texture -> upsample blur to N-1 texture with additive blending).

2

@fclem, do you know?

3

We are doing the same thing as the unity implementation.
I just triple checked for good measure and we do exactly the same thing.

Also, by doing the blur in chain, we only need one texture of each size for the downsampling

Yes that could be an optimization. But maybe it was this way to avoid some fixed function blending precision issue.

4

I also checked multiple times, fascinating, maybe I’m missing something.

Shouldn’t those two lines be consistent by both using last ?


1 Like
5

You are right the first one is incorrect (L.326). I changed it and did not find a huge difference. I don’t think it changes the result much, so I could commit that as a fix.

6

That’s what I thought; it’s hard to know what makes the bloom looks good or not without in depth experiments.

1 Like