Split opaque and transparent phases

[james-j-obrien]

Objective

Fixes #8089.

Solution

Splits the MainPass3dNode into 2 nodes, one for the opaque + alpha passes and one for the transparent pass.

---

Changelog

• Split MainPass3dNode into MainOpaquePass3dNode and MainTransparentPass3dNode
• Combine opaque and alpha phases in MainOpaquePass3dNode into one pass
• Create START_MAIN_PASS and END_MAIN_PASS empty nodes as labels
• Main pass becomes START_MAIN_PASS -> MAIN_OPAQUE_PASS -> MAIN_TRANSPARENT_PASS -> END_MAIN_PASS

Migration Guide

Nodes that previously added edges involving MAIN_PASS should now add edges to or from START_MAIN_PASS or END_MAIN_PASS respectively.

[IceSentry]

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.

[james-j-obrien]

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.

[JMS55]

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.

Sounds like a good solution for now. More indication that we should split up "node graph markers/labels" and actual running nodes though.

[JMS55]

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

[IceSentry]

LGTM, I didn't try running it, but the change seem good

[JMS55]

Tested it, lgtm!

[coreh]

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)

[kurtkuehnert]

Other than that I would split the transparent node and the reset viewport node this LGTM.

[kurtkuehnert]

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.

[james-j-obrien]

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.

[robtfm]

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?

[superdump]

Please address the merge conflicts and then we can get this merged.