What problem does this solve or what need does it fill?
Primitive shapes were added in #10466. It should be possible to render them using Bevy's gizmos. This would help unify APIs while also adding support for more gizmo shapes.
What solution would you like?
There's a few potential APIs I have in mind. One would be to have primitive_2d/primitive_3d methods for Gizmos:
fn draw(mut gizmos: Gizmos) {
// shape, position, rotation, color
gizmos.primitive_2d(Circle::new(2.5), Vec2::ZERO, 0.0, Color::CYAN);
gizmos.primitive_3d(Sphere::new(2.5), Vec3::ZERO, Quat::default(), Color::CYAN);
}
Here, each shape primitive should implement a trait like GizmoPrimitive2d/GizmoPrimitive3d so that the gizmos know how to draw them.
One issue with this approach is that you can't really control the detail. I'm not sure how to fix it nicely, but one approach could be to have the trait be given an associated type so that the methods can return different builder types for the different shapes, like the current CircleBuilder. It feels a bit verbose, but maybe it's necessary with this approach?
Another alternative is to have each shape primitive have its own gizmo method. This approach could support detail where applicable and support more configuration. Something like this:
fn draw(mut gizmos: Gizmos) {
// Notice how rotation isn't needed (for circles/spheres) because of custom impl
Circle::new(2.5).gizmo(&mut gizmos, Vec2::ZERO, Color::CYAN, SUBDIVISIONS);
Sphere::new(2.5).gizmo(&mut gizmos, Vec3::ZERO, Color::CYAN, SUBDIVISIONS);
}
If desired, Gizmos could still have primitive_2d/primitive_3d with default implementations.
Ideas and suggestions are welcome!
What problem does this solve or what need does it fill?
Primitive shapes were added in #10466. It should be possible to render them using Bevy's gizmos. This would help unify APIs while also adding support for more gizmo shapes.
What solution would you like?
There's a few potential APIs I have in mind. One would be to have
primitive_2d/primitive_3dmethods forGizmos:Here, each shape primitive should implement a trait like
GizmoPrimitive2d/GizmoPrimitive3dso that the gizmos know how to draw them.One issue with this approach is that you can't really control the detail. I'm not sure how to fix it nicely, but one approach could be to have the trait be given an associated type so that the methods can return different builder types for the different shapes, like the current
CircleBuilder. It feels a bit verbose, but maybe it's necessary with this approach?Another alternative is to have each shape primitive have its own gizmo method. This approach could support detail where applicable and support more configuration. Something like this:
If desired,
Gizmoscould still haveprimitive_2d/primitive_3dwith default implementations.Ideas and suggestions are welcome!