Ensure default Gizmos start rendering the same frame they are requested (Take 2)

[kfc35]

Objective

• Fixes Gizmos render unreliably #22438, Supersedes Fix: Draw Gizmos in the same frame they are created (by moving update_gizmo_meshes to run in PostUpdate) #22802
• Deal with what happens to Aabb, Frustum, and Light gizmos which, based on the system scheduling in their respective plugins, cannot be run in PostUpdate before AssetEventSystems.

Solution

• Adds the ability to initialize gizmo config groups with one of two different schedules for its “prepare gizmos for rendering” step (aka GizmoMeshSystems): In PostUpdate before AssetEventSystems (new scheduling) or In Last (previous scheduling). Preparing the gizmos for rendering before AssetEventSystems ensures that that asset extractor receives an asset event message about a newly added gizmo asset within the same frame.
• The DefaultGizmoConfigGroup uses the new schedule to ensure its gizmos can be drawn in the same frame they are requested (provided the request is before GizmoMeshSystems in PostUpdate)

I was unsuccessful in trying to port over Aabb, Frustum, and Light gizmos to this new schedule. If their PostUpdate systems were requested to run before GizmoMeshSystems, it would cause a cycle in the PostUpdate schedule, although the error message was completely unhelpful in this regard (there’s probably a bug in there somewhere):

Error when initializing schedule PostUpdate: schedule has 0 before/after cycle(s):

note: run with RUST_BACKTRACE=1 environment variable to display a backtrace

I was able to manually verify that Aabb would definitely have a cycle, but was unable to deduce the same for Frustum and Light gizmos. Since Aabb, Frustum, and Light gizmos work satisfactorily using the Last schedule without issue...

• Aabb, Frustum, and Light gizmos still use the Last schedule for GizmoMeshSystems (the previous scheduling). They function just fine, it is just that they start rendering one frame later, which I presume does not matter as much since they would usually be rendering for more than one frame anyway. I added a comment about them still using the Last schedule.
• Global gizmos now flush before GizmoMeshSystems in PostUpdate since its gizmos are part of the DefaultGizmoConfigGroup.

I’m open to hearing better names for init_gizmo_group_delayed_render

Testing

• After modifying the split_screen example to ShowFrustumGizmo’s for each camera, ran cargo run --example split_screen. The frustum gizmos look fine and does not lag when rotating the camera.
• cargo run --example debug_frustum_culling --features="free_camera” still looks good. Aabb’s correctly contain the shapes.
• The reproduction example in Gizmos render unreliably #22438 works as expected. After pressing D to hide the constant gizmo, Pressing A or S for the one frame gizmos renders for the frame.

[kfc35]

first of two differences between init_group_with_mesh_sys_schedule and the former init_gizmo_group

[kfc35]

& this is the second difference

[github-actions]

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!
You can review it at https://pixel-eagle.com/project/B04F67C0-C054-4A6F-92EC-F599FEC2FD1D?filter=PR-22964

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.

[github-actions]

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!
You can review it at https://pixel-eagle.com/project/B04F67C0-C054-4A6F-92EC-F599FEC2FD1D?filter=PR-22964

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.

[github-actions]

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!
You can review it at https://pixel-eagle.com/project/B04F67C0-C054-4A6F-92EC-F599FEC2FD1D?filter=PR-22964

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.