Repository navigation
Post processing doesn't work correctly when using multiple viewports #7435
Description
Bevy version
0.9 and main
What you did
In the split_screen example:
- Enable hdr on both cameras (enabling hdr only on one also breaks bevy, but this is a separate issue).
- Add
BloomSettings::default()to the left camera - Use an emissive color for the plane
I would have expected the left viewport to have bloom applied to it.
What went wrong
The bloom effect does not appear in the left viewport.
As you can see here, the bloom effect is indeed computed and generated correctly, but once it gets to the final upscaling pass, the texture modified by the post process is not used as an input.
I haven't investigated more than that, but it seems like the upscaling node is using the wrong texture when using multiple viewports combined with post processing.
Activity
rparrett commentedon Jan 31, 2023
related to #7361
IceSentry commentedon Jan 31, 2023
It might be related, but this happens with any post processing effect, not just bloom. Bloom is simply the easiest to test. For example, if I enable bloom on the right camera instead, it works as expected where only one camera has bloom applied.
Elabajaba commentedon Jan 31, 2023
Multiple cameras with multiple windows work fine (where each window has its own camera), but multiple cameras that composite to the same window don't.
Elabajaba commentedon Feb 1, 2023
From what I can tell, it only works for bloom because bloom works on a separate set of textures that are limited to the view.
Fxaa (and my CAS pr) use the main_texture and end up applying to everything on screen instead of only the right camera's viewport.
Elabajaba commentedon Feb 1, 2023
Debugging it on discord with @robtfm, this is a bug with Msaa. In the 2nd pass it's reading the
main_texture_sampledfrom the previous pass, which doesn't have any post processing applied.Disabling Msaa also revealed another bug, where because it now relies on the previous
main_texture_athe output is reliant on what the last pass that wrote tomain_texture_awas. With only bloom, it works fine (by accident), but add Fxaa and you end up with a double tonemapped final output becausemain_texture_a's was tonemapped before it started rendering the 2nd viewport.IceSentry commentedon Feb 1, 2023
Right, the other issue I had was for a post process effect that uses multiple textures like bloom does so I mistakenly assumed it was an issue with all post processing.
robtfm commentedon Feb 1, 2023
there's a few post-processing issues compounding one another here. i think if we do the below, then almost everything works as intended:
the above still doesn't solve problems with overlapping non-destructive post-processing cameras (i.e. cameras that write to previously written pixels and don't overwrite every pixel in their viewport, then apply postprocessing). bloom (e.g.) applied to these cameras will affect previous camera's pixels as well because they are unavoidably there in the bloom input texture. you can avoid that in this particular case by running the bloom cameras first, but there's no general solution while rendering to the same texture.
the full solution for that is rendering to multiple texture targets and composing, which is supported already but requires a bit of extra work (see the render-to-texture example).
robtfm commentedon Feb 1, 2023
one more, though it doesn't matter in the core pipeline and i believe is already addressed by the bloom rework:
Keelar commentedon Feb 1, 2023
Could this also be related to #5721? Seems like there are some similarities, as they are both influenced by MSAA and camera rendering order. Apologies if they're unrelated. I'm not too familiar how the engine works at a low level yet but some of the discussion in here reminded me of that issue so I thought it was worth bringing up.
Camera Output Modes, MSAA Writeback, and BlitPipeline (#7671)
Camera Output Modes, MSAA Writeback, and BlitPipeline (bevyengine#7671)