Replies: 7 comments 11 replies
-
Ping @bevyengine/rendering-team :) Thanks for surfacing this, I suspect we'd be open to debate on all of those points. |
Beta Was this translation helpful? Give feedback.
-
This user seems to be very confident about an issue that doesn't exist. Bloom is applied before tonemapping in bevy. https://github.com/bevyengine/bevy/blob/main/crates/bevy_core_pipeline/src/bloom/mod.rs#L80 It's very possible there's other things that are wrong with it, but this is not one of them. |
Beta Was this translation helpful? Give feedback.
-
I agree that bevy's bloom doesn't look that great to me - no offense to any of the authors. I think this is mostly because of the tonemapping choice. Currently tonemapping is applied to luminance only, which I think is unusual. Here's a gradient comparison between tonemapping the luminance only (top) and tonemapping RGB individually (bottom) as brightness increases (by On the other hand, the YouTube comment comes over as particularly entitled, even if it was not meant this way. I disagree that bloom after tonemapping (or on SDR content) is a mistake in general. Also, as IceSentry mentioned, bevy already does this correctly according to the comment. It usually looks better in HDR scenarios, I agree. But even if it doesn't accurately model the real world, that doesn't mean that it can't look good and be of value artistically. The same thing goes for the threshold value. Even modern games (Doom for example) use threshold values to "contain" the bloom effect a bit more, and allow for exaggerated highlights without blurring dim areas too much. Again, not physically accurate but that doesn't invalidate its usefulness when applied with care. |
Beta Was this translation helpful? Give feedback.
-
I think it makes sense to give developers artistic control beyond what is realistic while keeping the defaults as physically accurate as possible. The issue with a non-zero threshold besides not being physically accurate is that it can make the bloom effect very scene dependent making it hard to pick good defaults. Similar to how the goal of PBR is to make materials look consistent under different lighting conditions, I'd say it makes sense to apply the same approach to the bloom effect which attempts to emulate a real physical phenomenon. Therefore I would argue to change the default bloom settings to have a default threshold of zero and a linear response. Another issue with Bevy's current bloom Implementation is that it is not energy preserving. It increases the overall brightness of the image due to using additive blending which is not physically accurate. A common approach that addresses this seems to be to linearly interpolate between the original image and the bloom output depending on the intensity. There is a great video that outlines what a completely realistic bloom effect would involve, depending on the shape of the camera aperture. While probably not feasible in realtime it gives a good theoretical overview on how bloom works: Another good resource is this guest article on learnopengl.com which addresses the threshold and energy conservation topics: |
Beta Was this translation helpful? Give feedback.
-
Working on a fix to these issues: #6677 |
Beta Was this translation helpful? Give feedback.
-
Hi (i'm the Youtube user) |
Beta Was this translation helpful? Give feedback.
-
@alice-i-cecile @cart The recent comment should be removed. |
Beta Was this translation helpful? Give feedback.
-
In a recent YouTube video on Bevy, a commenter says:
The user was hesitant to open an issue as they weren't certain of their understanding of the bloom implementation, but I believe it's important to at least have it out there.
Beta Was this translation helpful? Give feedback.
All reactions