Better bloom blending / bloom rework

[CptPotato]

Godot version: 3.0.2

This one might be a bit nit-picky but I think it's still worth mentioning:

At the moment, bloom is blended after tonemapping & gamma correction, loosing a lot of its impact (because it's not blended in HDR). On top of that it's mixed using modes that you might find in image editing software (soft light, screen, etc.) but which I consider unfit for the job. One of the downsides is that bloom looks pretty dull and/or causes a lot of overexposure depending on which mode you choose.

The usual, more physically correct (and in my opinion best) approach is using a mix or add operation in linear space before the tonemapping, utilizing the full range of colors.

In pseudo-code, this is what's currently done in the shader:

Color = Tonemap(Color, Whitepoint);
Glow = Tonemap(Glow, Whitepoint);
Color = GammaCorrect(Color);
Glow = GammaCorrect(Glow);
Color = ApplyBloom(Color, Glow, Mode); // mix color with bloom using the selected blending mode

And this is what I'd suggest (being done in pretty much all current gen titles)

Color = mix(Color, Glow, BlendFactor); // blend in LINEAR space for a physically based approach (alternative: additive blending)
Color = Tonemap(Color, Whitepoint); // tonemapping and gamma correction comes last!
Color = GammaCorrect(Color);

And lastly, if the current blending modes are going to stay in the long run, I'd like to suggest some improvements for the "soft light" algorithm which seems unnecessarily complex right now:
It uses a lot of branching which is generally considered bad practise in shaders (see the following link) especialy since it's the default mode. I'd suggest an alternate algorithm which looks similar but doesn't use any branching.

[reduz]

Hi, I understand your concern and it's true that the way Bloom is done is not physically correct. In fact, the way you mention is how I approached it first, but later found it very difficult to tweak and adjust for a specific look, or control cases of excessive bleeding.

However, the decision to do it like this is more for artistic reasons than being physically correct. Current implementation is easier for artists to tweak, which is what the aim of most of Godot rendering is.

[reduz]

Ah, thanks for the softlight link, that will be definitely useful

[reduz]

That said, doing it linear space should be easy to add as an extra option, if there is a good use case for it.

[CptPotato]

Thanks for all the info, I'd love to see an optional linear approach. I'm actually glad you understood what I was rambling about... I wasn't sure if anyone would get it as it's a pretty low-level thing most devs don't get it touch with directly.

I once made a dirty implementation of what I suggested along with one or two additional fixes and it worked pretty much as I wanted it to. That being said I'm also kind of biased since this is the way I've implemented it in applications outside of Godot recently.

The soft light algorithm I posted is based on one that I've written a while ago. It looked pretty much exactly like the one used in GIMP as far as I can tell. I adjusted it a bit so it's not too different from what's currently used.

Anyway, if you/anyone needs a hand with what I suggested I'm happy to help with shader source code or something. Implementing it into Godot is another thing... I feel like I'd break everything I touch.

[Zylann]

It seems I misunderstood this issue when I first read it, but maybe it answers a nagging question I had when I looked at the TPS demo:

The demo has plenty of lights which glow in this unrealistic saturated way. Making the color whiter would loose the point of coloring it in the first place.
If you were to make a proper lightsaber or want to achieve better photorealism, that's not how light should look like.

For example, from a render by @CptPotato, this is what I would have expected:

Now I understand that having one or the other would be an artistic choice, but I'd like the possibility for Godot to offer ways to achieve both (currently I have no idea how to do the latter...)

[CptPotato]

Yeah, so the second screenshot Zylann posted is from my own deferred & forward hybrid renderer.

The bloom is done in HDR (Godot should use a similar approach) and blended in the way I described in the original post. Notice how it looks a lot softer and has a nicer saturation and color falloff. Additionally there is a little saturation trick I'm using to make sure even highly saturated colors "fade to white" when bright enough.

I made a fork and will be trying to implement this (along with fixing #19163, as it's related and in the same shader file) somewhere in the upcoming weeks.

[golddotasksquestions]

As an artist, I would like to have as precise control about the bloom color mixing as possible. If there are defaults that look good and/or realistic, that's a big plus.
Currently however there is neither really. Almost no intention driven control with the WE node, and it does not really look realistic either out of the box. Intention driven would mean to be able to pick exactly which color is in the center, what is the gradient of colors fading out from it and having options for how are both blending with the underlying pixels.
Right now all you can do is play around with arbitrary levers and numbers and somehow hope you will end up with a result you like. This can take forever and is really hard to replicate and worst: You cannot aim for a certain look.

[CptPotato]

I'm fine without having a tint option for the bloom effect but I guess that's just personal preference. To get the most realistic look, use Screen as blending mode and turn down the glow intensity quite a bit (I'm using around 0.05 to 0.10).

[RonanZe]

I also find the actual Glow hard to setup.
The overall feeling with the Godot render system right now is that is a bit hard to setup compare to someting like Eevee

It's good to have control but it's even better when the render help you to go in the right direction.
For exemple, nobody want to see someting like the "Blender Internal" again and all the hours spend to tweak all the parameters to have good enough renders.

Why not get the inspiration from Eevee's Bloom? It give realistic results and the "Color" parameter can really help to change the mood of a scene.
Is it based on the same render technics that the Glow from Godot?

Maybe that is for an another topic but,

Other stuff would be good to have like Curve for color management that is use a lot to punch the highlights and the shadows in post prod.
And is the tonemap system working in the right way? The results I have seems less consistent than the Eevee's one.

[Calinou]

@RonanZe Glow has been reworked in the master branch, give it a try (if you can build Godot from source). See Vulkan Progress Report #6 for details.

[RonanZe]

Nice to hear that!

I have build the master yesterday under linux but it's difficult to test it because I can import an old demo scene (everything is black) and I can't assign the color atlas texture by drag and drop in the editor.

I'll give an other try today with an Eevee scene I'm working on to see the differecences and the improvements in Godot

[RonanZe]

I've played with the master branch, Godot 3.2 and Eevee today.

Maybe it's better that the old one because everything is compute in the right order.
But for me the Glow seems still diffcult to setup compare to Eevee's Bloom effect.

It's difficult the know which Levels to put on or off to get a good result, what is the difference between Strengh and Intensity and what the HDR stuffs are meaning here.
It would be a good thing to have a Color option like in Eevee (I can give an exemple to show the benefits of it if needed)

And it's buggy atm --> you have a lot of flickering. it's like you dont have the right upscale and that you can see the low res image that is used to create the effect.

I'll do more accurate comparisons between Godot 3.2 and master when I will be able to load again an hdr image in the settings.

[Calinou]

And it's buggy atm --> you have a lot of flickering. it's like you dont have the right upscale and that you can see the low res image that is used to create the effect.

Did you enable Bicubic Upscale?

[RonanZe]

I can't find the option in a fresh master build. Is it in the same place has in 3.2 ?

[Calinou]

@RonanZe It was moved to the Project Settings as it's a quality setting. (Godot 4.0 will centralize quality settings there to make them easier to adjust at the same time.)

That said, bicubic upscale is already the default. Can you upload a minimal project with the glow configured? Also, could you record a video and upload it somewhere?

[RonanZe]

The upscale is on. Here is a video + the project:
2020-05-10 17-08-00.zip
Great-Village.zip

Can you see the flickerings?

[Calinou]

Can you see the flickerings?

Yes, but I don't know how to solve them exactly.

[clayjohn]

That's not an issue with the upscale, it seems the glow is really sensitive to changes in brightness in the original scene. The flickering is caused (from what I could tell when running it) from the little bumps on the battlement combined with the glow being sensitive to changes.

I believe this issue what hdr_luminance and hdr_scale are supposed to fix, but they are having no effect in the test scene, would be worth opening a new issue so this can be investigated.

[Calinou]

This should be fixed in the master branch thanks to the Vulkan renderer, closing.

Please create a new bug report for the issues related to oversensitivity to brightness changes in glow.

If there are other tonemapping/bloom changes that should be made, please create a new proposal on the Godot proposals repository after searching for possible duplicates.

Edit: For reference, this has been addressed by #52476 in Godot 3.4 and later. Use the ACES Fitted tonemap mode in Godot 3.x, or the ACES tonemap mode in Godot 4.x.