Split opaque and transparent phases #8090
Conversation
|
I'd like to keep the ability of scheduling things relative to a MAIN_PASS that isn't concerned about transparency. Unfortunately, that might mean adding a START_MAIN_PASS/END_MAIN_PASS empty node. |
I had the same thought, it did seem odd going into the ui and pbr node and having to just know which pass to order relative to, happy to also add those if we think it would help with usability. |
Sounds like a good solution for now. More indication that we should split up "node graph markers/labels" and actual running nodes though. |
There was a problem hiding this comment.
Looks good to me so far, thanks for the PR :)
Here's my requested changes:
- Use empty nodes for start/end main pass, and use labels relative to those for things like bloom (update the migration guide)
- Combine the opaque/alpha render passes for better performance
- Add doc comments to the two node types, indicating that they do opaque+alpha and transparency, respectively (use the actual RenderPhase names within the docs).
- Add a changelog noting the split
james7132
added
C-Feature
|
Ooo this is really nice, since it allows a more “pluggable” approach with the (potential) transmissive phase and might allow in the future to have it also optionally go after the transparent phase (for scenes where you also want to refract transparent meshes) |
| #[cfg(feature = "webgl")] | ||
| if camera.viewport.is_some() { | ||
| #[cfg(feature = "trace")] | ||
| let _reset_viewport_pass_3d = info_span!("reset_viewport_pass_3d").entered(); | ||
| let pass_descriptor = RenderPassDescriptor { | ||
| label: Some("reset_viewport_pass_3d"), | ||
| color_attachments: &[Some(target.get_color_attachment(Operations { | ||
| load: LoadOp::Load, | ||
| store: true, | ||
| }))], | ||
| depth_stencil_attachment: None, | ||
| }; | ||
|
|
||
| render_context | ||
| .command_encoder() | ||
| .begin_render_pass(&pass_descriptor); | ||
| } |
There was a problem hiding this comment.
I think this should be a separate node as well. We want this even when no transparent node is added. Additionally, we could only insert it on WebGL builds.
There was a problem hiding this comment.
I think this is fair. It does seem to be a mix of concerns and could be problematic for those who want to build their own render graph without a transparent pass. However it does also mean those users would have to know to add the reset viewport node. Conditionally adding the node for web builds could be a good solution as I wouldn't want to add another empty node if we could avoid it.
james7132
added
the
S-Ready-For-Final-Review
There was a problem hiding this comment.
lgtm
i do agree that the viewport reset pass should not be here, but i don't think it's necessary to change it in this PR since it's a bit of a fudge already.
specifically, this breaks currently if people don't set viewport state immediately after any prior pass that sets a viewport ... the generally webgl-safe approach seems to be setting your own viewport explicitly every time or resetting the viewport with an empty pass every time. perhaps we could have the TrackedRenderPass set viewport automatically in webgl, but maybe it needs the viewport size which isn't available? so maybe the TrackedRenderPass could just run an empty pass for you if you don't explicitly set a viewport. should that be at the end of a viewport-setting pass or the beginning of a non-viewport-setting pass? can we make it conditional to when the viewport was previously set if the latter? is there anything we can do to make sure people are using tracked render passes instead of native ones? can we just punt the whole issue until webgpu?
|
Please address the merge conflicts and then we can get this merged. |
Selene-Amanita
added
the
M-Needs-Migration-Guide
Objective
Fixes #8089.
Solution
Splits the MainPass3dNode into 2 nodes, one for the opaque + alpha passes and one for the transparent pass.
Changelog
START_MAIN_PASSandEND_MAIN_PASSempty nodes as labelsSTART_MAIN_PASS -> MAIN_OPAQUE_PASS -> MAIN_TRANSPARENT_PASS -> END_MAIN_PASSMigration Guide
Nodes that previously added edges involving
MAIN_PASSshould now add edges to or fromSTART_MAIN_PASSorEND_MAIN_PASSrespectively.