-
-
Notifications
You must be signed in to change notification settings - Fork 4.5k
Add debug wireframe rendering for Aabb, Frustum, and Sphere #4082
Copy link
Copy link
Open
Labels
A-RenderingDrawing game state to the screenDrawing game state to the screenA-UtilsUtility functions and typesUtility functions and typesC-FeatureA new feature, making something new possibleA new feature, making something new possibleC-TestingA change that impacts how we test Bevy or how users test their appsA change that impacts how we test Bevy or how users test their appsC-UsabilityA targeted quality-of-life change that makes Bevy easier to useA targeted quality-of-life change that makes Bevy easier to use
Description
Metadata
Metadata
Assignees
Labels
A-RenderingDrawing game state to the screenDrawing game state to the screenA-UtilsUtility functions and typesUtility functions and typesC-FeatureA new feature, making something new possibleA new feature, making something new possibleC-TestingA change that impacts how we test Bevy or how users test their appsA change that impacts how we test Bevy or how users test their appsC-UsabilityA targeted quality-of-life change that makes Bevy easier to useA targeted quality-of-life change that makes Bevy easier to use
What problem does this solve or what need does it fill?
Debugging intersections for the primitives currently used for culling for rendering is difficult without visualisation.
What solution would you like?
Add debug wireframe rendering for Aabb, Frustum, and Sphere. Mesh types exist for all but Frustum so those should probably be reused, and then there will need to be a way to differentiate debug meshes and general meshes so that it doesn’t create a feedback loop of a mesh having an Aabb, with a debug mesh for the Aabb that itself gets an Aabb that gets a debug mesh…
What alternative(s) have you considered?
None yet. Just noting that this would be good to do.
Additional context
@aevyrie ’s bevy_mod_bounding has support for this already and there’s the primitive shapes RFC.