Add debug wireframe rendering for Aabb, Frustum, and Sphere

[superdump]

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.

[jakobhellermann]

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…

The way I imagined how this feature would works is not not inserting a mesh of the bounding box into the world, but having a general "draw these lines somehow" mechanism like bevy_polyline or bevy_debug_lines and having a system that iterates over &Aabb's and draws debug lines corresponding to the bounding box. That way, no entities would be actually added to the world.

Alternatively, there could be one "hollow box" mesh, and we add an Extract system that queries for &Aabb and inserts a new entity into the render world that will draw the Aabb. Again, no entities in the main world so no need to differentiate the debug mesh.

[aevyrie]

I used bevy_polyline for the debug wireframes in bevy_mod_bounding, although I was setting them as child entities. I don't think it runs into the recursive loop of AABBs issue because I'm inserting a polyline, not a mesh, therefore no AABB will be generated from the debug wireframe.

It might be better - as @jakobhellermann mentions - to take an immediate mode rendering approach and convert all AABBs into wireframes in a function call without generating any entities. We could do this without needing any fancy line rendering to be implemented in bevy, just draw wireframe box meshes in the render subapp.

[superdump]

I had started on this and was adding debug meshes similar to bevy_mod_bounding. I think I used a new component type and side-stepped the recursiveness that way. With an immediate mode approach without caching the vertices, they would have to be recalculated every frame. I think calculating the vertex positions and skipping transforms could be practically simpler (I was having problems with Frustum) but it could also have a negative performance impact, perhaps. I suppose bounding volumes tend to have few vertices though so maybe it's fine...

[nerdachse]

Any progress on this?

[tim-blackbird]

An immediate mode rendering api was added and you can enable drawing oriented bounding boxes via GizmoConfig or the AabbGizmo component.
Drawing axis aligned bounding boxes, bounding spheres, and frustums has not been implemented yet.

[superdump]

We now have this for aabbs, spheres, and camera frusta, right @devil-ira ?

[tim-blackbird]

The pr for frusta isn't merged yet, but I'll set this issue to be closed when it does