[Merged by Bors] - Revamp Bloom

[JMS55]

Huge credit to @StarLederer, who did almost all of the work on this. We're just reusing this PR to keep everything in one place.

Objective

1. Make bloom more physically based.
2. Improve artistic control.
3. Allow to use bloom as screen blur.
4. Fix Bloom results in transparency across frame #6634.
5. Address Comment on bloom implementation #6655 (although the author makes incorrect conclusions).

Solution

1. Set the default threshold to 0.
2. Lerp between bloom textures when composite_mode: BloomCompositeMode::EnergyConserving.
3. Use a parametric function to control blend levels for each bloom texture. In the future this can be controlled per-pixel for things like lens dirt.
4. Implement BloomCompositeMode::Additive` for situations where the old school look is desired.

Changelog

• Bloom now looks different.
• Added BloomSettings:lf_boost, BloomSettings:lf_boost_curvature, BloomSettings::high_pass_frequency and BloomSettings::composite_mode.
• BloomSettings::scale removed.
• BloomSettings::knee renamed to BloomPrefilterSettings::softness.
• BloomSettings::threshold renamed to BloomPrefilterSettings::threshold.
• The bloom example has been renamed to bloom_3d and improved. A bloom_2d example was added.

Migration Guide

• Refactor mentions of BloomSettings::knee and BloomSettings::threshold as BloomSettings::prefilter_settings where knee is now softness.
• If defined without ..default() add ..default() to definitions of BloomSettings instances or manually define missing fields.
• Adapt to Bloom looking visually different (if needed).

[james7132]

@JMS55 this fixes #2264. Could you add that to the PR description? Also a more fleshed out Migration Guide is probably needed.

[JMS55]

@james7132 mentioned that issue. What should I add to the migration guide?

[james7132]

A general guide on changes that need to be made. This one has an artistic impact so it may be harder to write, but the migration guide is intended as a way to document what is necessary to deal with the changes. This section is used to automatically generate the migration guide for the next version, so simply saying "adapt to X" is less of a guide and more of a command in this case. Either rewording it or providing concrete code examples on how to address the breaking changes would be for the best.

[CptPotato]

Thanks for the quick fix, imo ACES is a decent default 👍

A general guide on changes that need to be made. This one has an artistic impact so it may be harder to write, but the migration guide is intended as a way to document what is necessary to deal with the changes.

One thing that comes to mind is that ACES has a higher contrast, darker shades that looked fine before might get a bit too dark now. So making some lighting adjustments like lifting the ambient light brightness could help.

But it very much depends on the specific case I guess.

Also, small nit about the example:

• the parameters didn't seem to be clamped, not sure if this is on purpose
• the background color is rather bright, I think a darker one might work better

[coreh]

🎉 This looks (subjectively) a bit more natural than the previous version, and it's also more intuitive to control.

One thing I noticed is that it seems to be dependent on the aspect ratio of the window. In the default configuration, it produces a bloom that's slightly wider than taller. Using more extreme values for the window size, you can make it more apparent. It only seems to produce 100% unbiased results on a square resolution. I suspect this could produce some (minor) graphical fidelity issues for users on ultra-wide monitors:

I see that there's some math using the texel size where you do the taps, maybe it's slightly off somehow?

[pkupper]

In a more complex scene I'm getting a bunch of black squares, that seem to mostly appear on top of dark objects. Possibly a floating point error (e.g. divide by zero) propagating through the downsampling/upsampling chain.

[JMS55]

One thing I noticed is that it seems to be dependent on the aspect ratio of the window

Yeah I noticed that in my 4k monitor - it looks subtly different in 4k fullscreen vs 1080p windowed. I didn't think it was a huge deal at the time - most uses of bloom won't be on perfectly round spheres with a static camera. I didn't think about ultrawides though. I'll look into this, see if there's a way to fix it. Some quick research says using fixed resolutions for bloom mips might work better than arbitrary half resolutions of the current screen size. I'll have to experiment with this.

In a more complex scene I'm getting a bunch of black squares, that seem to mostly appear on top of dark objects. Possibly a floating point error (e.g. divide by zero) propagating through the downsampling/upsampling chain.

The article I was basing things on ran into the same issue (See "Bonus material 0" https://learnopengl.com/Guest-Articles/2022/Phys.-Based-Bloom). Also, https://docs.unity3d.com/Packages/com.unity.render-pipelines.high-definition@15.0/manual/Post-Processing-Propagating-NaNs.html. I didn't want to copy any "hacks" without a good test case to reproduce the issue, but now that it's come up I'll add it in my next set of commits. Please let me know if it fixes it, and thank you for testing it out! Also, how does the scene look otherwise?

the parameters didn't seem to be clamped, not sure if this is on purpose

Not sure what we should do about this. I'm thinking for the example, I clamp the values to be valid. Bloom code-wise, I'll probably clamp the values before sending them to the shader, and add a note about that to the documentation.

[JMS55]

In a more complex scene I'm getting a bunch of black squares, that seem to mostly appear on top of dark objects.

@pkupper can you verify if this has been fixed with my recent commits?

[JMS55]

The examples are currently broken, I get an error about view not being in scope when enabling a different tonemapper.
color = saturation(color, view.color_grading.pre_saturation);

EDIT: Fixed

[JMS55]

@robtfm came up with a great improvement to make bloom look more consistent at various resolutions.

The only thing really missing now is the glowing bevy logo in the bloom_2d example looks kinda bad. Rather than adjust the color values in code, it would be better to encode the image such that the white birds are bright, but the black circle they are on aren't. The way it is now, the whole thing kinda fades to white and looks bad and washed out. Not a huge blocker though, and we could just remove it. We've had questions in the past on how to add bloom to a 2d sprite, so that was my attempt at trying to show it. Didn't work out that well.

[robtfm]

LGTM.

i think there's still some banding evident at some widths and with some settings (with high intensity, low high-freq, resizing the width slowly i get banding artifacts at some resolutions). this might be a problem for dynamic upsizing in future. but it's only in some configurations and unless the window size is changing it isn't very evident so i think it's good for now.

[JMS55]

this might be a problem for dynamic upsizing

Bloom will run after those at display resolution. It's only the prepass/main pass/etc that render at a reduced resolution.

[superdump]

bors r+

[bors]

Pull request successfully merged into main.

Build succeeded:

• build-and-install-on-iOS
• build-android
• build (macos-latest)
• build (ubuntu-latest)
• build-wasm
• build (windows-latest)
• build-without-default-features (bevy)
• build-without-default-features (bevy_ecs)
• build-without-default-features (bevy_reflect)
• check-compiles
• check-doc
• check-missing-examples-in-docs
• check-missing-features-in-docs
• ci
• markdownlint
• msrv
• run-examples
• run-examples-on-wasm
• run-examples-on-windows-dx12