Break dependency from bevy_anti_alias on bevy_post_process by splitting PostProcess set#23098
Conversation
|
Your PR caused a change in the graphical output of an example or rendering test. This might be intentional, but it could also mean that something broke! If it's expected, please add the M-Deliberate-Rendering-Change label. If this change seems unrelated to your PR, you can consider updating your PR to target the latest main branch, either by rebasing or merging main into it. |
1 similar comment
|
Your PR caused a change in the graphical output of an example or rendering test. This might be intentional, but it could also mean that something broke! If it's expected, please add the M-Deliberate-Rendering-Change label. If this change seems unrelated to your PR, you can consider updating your PR to target the latest main branch, either by rebasing or merging main into it. |
atlv24
left a comment
There was a problem hiding this comment.
I think the naming of the new sets needs some more thinking. Taa running in PostProcess doesnt make sense. How about
EarlyPostProcess
AntiAlias
PostProcess
So the anti aliasing actually runs in the AntiAlias set?
|
the anti aliasing example crashes on a dependency cycle: |
f47c8c1 to
78937aa
Compare
|
Definitely made a mistake with the ordering, |
atlv24
left a comment
There was a problem hiding this comment.
We should probably put the rest of the anti aliasing solutions into the AntiAlias set
bevy_anti_alias doesn't depend on bevy_post_processbevy_anti_alias on bevy_post_process
|
Your PR caused a change in the graphical output of an example or rendering test. This might be intentional, but it could also mean that something broke! If it's expected, please add the M-Deliberate-Rendering-Change label. If this change seems unrelated to your PR, you can consider updating your PR to target the latest main branch, either by rebasing or merging main into it. |
|
Hmm, TAA flickers with In // TAA is ideally applied after tonemapping, but before post processing
// Post processing wants to go before tonemapping, which conflicts
// Solution: Put TAA before tonemapping, tonemap TAA input, apply TAA, invert-tonemap TAA outputI think this might be a little more complicated to complete |
This is resolved my merging main |
alice-i-cecile
left a comment
There was a problem hiding this comment.
I like the explicit AntiAlias step. Can you update the PR description and title?
bevy_anti_alias on bevy_post_processbevy_anti_alias on bevy_post_process by splitting PostProcess ser
bevy_anti_alias on bevy_post_process by splitting PostProcess serbevy_anti_alias on bevy_post_process by splitting PostProcess set
|
@kfc35 Thanks for your review, this has made me check this PR from first principles. My read of the relevant systems is as follows:
The goal is to remove blue/red edges (all others are fine). Therefore, we only really need two sets, Graph generation
|
354e44f to
927e0d5
Compare
…ng PostProcess set
kfc35
left a comment
There was a problem hiding this comment.
Nice, this looks great! Thanks for making the graph; I should keep https://graph.flyte.org/ handy too. This just motivates me to start thinking about automatic schedule visualizations for bevy systems...
tychedelia
left a comment
There was a problem hiding this comment.
Nice investigation, thanks.
# Objective Fixes #23472 (and a similar issue for wireframes) When `EarlyPostProcess` was created in #23098, some existing systems that were scheduled between `MainPass` and `PostProcess` weren't updated. This caused them to race with TAA, which causes flickering and other artifacts. ## Solution Order them relative to `EarlyPostProcess` instead. ## Testing `cargo run --example scrolling_fog` for volumetric fog. For wireframes you can see flickering on main if you add TAA to `wireframe.rs`: ```diff index 74376ab..4ac71fcdc 100644 --- a/examples/3d/wireframe.rs +++ b/examples/3d/wireframe.rs @@ -114,6 +114,8 @@ fn setup( commands.spawn(( Camera3d::default(), Transform::from_xyz(-2.0, 2.5, 5.0).looking_at(Vec3::ZERO, Vec3::Y), + Msaa::Off, + TemporalAntiAliasing::default(), )); ```
…itting `PostProcess` set (bevyengine#23098) # Objective - During bevyengine#22144 , we slightly linearlised the crate build, by explicit dependency on system ordering. [See this comment](https://github.com/bevyengine/bevy/pull/22144/changes#r2697878715) ## Solution - Split `PostProcess` set into `EarlyPostProcess` and `PostProcess` sets - Move `taa` and `dlss` into `EarlyPostProcess` <img width="309" height="539" alt="aa-no-pp" src="https://github.com/user-attachments/assets/bb32b71a-4743-46e4-ad2c-f06ef7db854f" /> ## Testing - CI - `cargo run --example anti_aliasing`
# Objective Fixes bevyengine#23472 (and a similar issue for wireframes) When `EarlyPostProcess` was created in bevyengine#23098, some existing systems that were scheduled between `MainPass` and `PostProcess` weren't updated. This caused them to race with TAA, which causes flickering and other artifacts. ## Solution Order them relative to `EarlyPostProcess` instead. ## Testing `cargo run --example scrolling_fog` for volumetric fog. For wireframes you can see flickering on main if you add TAA to `wireframe.rs`: ```diff index 74376ab..4ac71fcdc 100644 --- a/examples/3d/wireframe.rs +++ b/examples/3d/wireframe.rs @@ -114,6 +114,8 @@ fn setup( commands.spawn(( Camera3d::default(), Transform::from_xyz(-2.0, 2.5, 5.0).looking_at(Vec3::ZERO, Vec3::Y), + Msaa::Off, + TemporalAntiAliasing::default(), )); ```

Objective
RenderGraphwith systems #22144 , we slightly linearlised the crate build, by explicit dependency on system ordering. See this commentSolution
PostProcessset intoEarlyPostProcessandPostProcesssetstaaanddlssintoEarlyPostProcessTesting
cargo run --example anti_aliasing