Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Retained gizmos #9178

Open
LeshaInc opened this issue Jul 16, 2023 · 4 comments
Open

Retained gizmos #9178

LeshaInc opened this issue Jul 16, 2023 · 4 comments
Labels
A-Gizmos Visual editor and debug gizmos C-Feature A new feature, making something new possible

Comments

@LeshaInc
Copy link
Contributor

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

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
@LeshaInc LeshaInc added C-Feature A new feature, making something new possible S-Needs-Triage This issue needs to be labelled labels Jul 16, 2023
@nicopap nicopap added A-Gizmos Visual editor and debug gizmos and removed S-Needs-Triage This issue needs to be labelled labels Jul 18, 2023
@nicopap
Copy link
Contributor

nicopap commented Jul 18, 2023

@nicopap
Copy link
Contributor

nicopap commented Jul 18, 2023

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
Copy link
Contributor

SpecificProtagonist commented Jul 18, 2023

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
Copy link
Member

aevyrie commented Oct 19, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Gizmos Visual editor and debug gizmos C-Feature A new feature, making something new possible
Projects
None yet
Development

No branches or pull requests

4 participants