Retained gizmos

[LeshaInc]

What problem does this solve or what need does it fill?

Currently gizmos are global and are rebuilt every frame. This is fine for debugging small scenes. On big scenes, however gizmos can incur a very high performance penalty, making the app unresponsive. A notable example is collider visualization in bevy_rapier and bevy_xpbd. Colliders shapes are static, yet their gizmos are rebuilt every frame and don't use any frustum culling. This is especially bad for static geometry expressed in TriMesh colliders, which can have thousands of faces.

bevy_gizmos can't possibly handle rendering millions of dynamic lines (of which only a fraction are actually visible). Frustum culling in bevy_gizmos won't help, since it would have to run per-line, and not per-entity.

Adding retained gizmos would help with entity-related debug information, like AABBs, colliders, axis, direction vectors, etc, all of which would be needed in a future editor.

What solution would you like?

A retained API for building gizmo meshes:

• trait AppendLines or something similar would provide default implementation for all methods from today's Gizmos .
• Gizmos would implement AppendLines, so its API won't suffer breaking changes
• Gizmo asset for storing retained gizmos, either would implement AppendLines directly, or through some sort of a GizmoBuilder
• GpuGizmo would store the GPU vertex buffer for a corresponding Gizmo
• All entities with GizmoBundle { gizmo, transform, visibility } would be displayed just like regular gizmos

What alternative(s) have you considered?

• Optimizing Gizmos. It isn't clear how, though.
• Using a wireframe Mesh for gizmos. This actually sounds good, but an ergonomic API for constructing such meshes should exist (mirroring all the present Gizmos methods)

Previous work

• bevy_polyline

Extra considerations

• AABB debug rendering should probably be implemented in terms of this retained API, so that frustum culling works.
• Preferably there should be batching when drawing the same gizmo asset multiple times

[nicopap]

• related: #9187

[nicopap]

yeah, something resembling wireframes but using gizmos instead of line rendering would be really nice. Since the gizmo line implementation is more performant than wireframes.

[SpecificProtagonist]

also related: #9153, which similar to AppendLines moves the functions on Gizmos to GizmosBuffer and exposes that, which means data still needs to be sent to the GPU each frame, but you don't need to be gathered and encoded it each time.

[aevyrie]

bevy_polyline uses the same API as meshes or other assets, which is worth considering. For games that want to render polylines like meshes, it would seem desirable if they had the same API.