-
-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
Comments
|
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. |
also related: #9153, which similar to |
|
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 inbevy_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'sGizmos
.Gizmos
would implementAppendLines
, so its API won't suffer breaking changesGizmo
asset for storing retained gizmos, either would implementAppendLines
directly, or through some sort of aGizmoBuilder
GpuGizmo
would store the GPU vertex buffer for a correspondingGizmo
GizmoBundle { gizmo, transform, visibility }
would be displayed just like regular gizmosWhat alternative(s) have you considered?
Gizmos
. It isn't clear how, though.Mesh
for gizmos. This actually sounds good, but an ergonomic API for constructing such meshes should exist (mirroring all the presentGizmos
methods)Previous work
Extra considerations
The text was updated successfully, but these errors were encountered: