bevyengine / bevyengine/bevy

Retained gizmos

Open
#9,178 4 comments 0 reactions 0 assignees View on GitHub
A-Gizmos C-Feature
Dominant language
Rust
Stars
48.2k
Forks
4.8k
Avg merge
3d 22h
Merged PRs (30d)
161

Description

## 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](https://github.com/ForesightMiningSoftwareCorporation/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

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.