bevyengine / bevy

A refreshingly simple data-driven game engine built in Rust
https://bevyengine.org
Apache License 2.0
32.97k stars 3.2k forks source link

Gizmos primitives by ref #13427

Closed lynn-lumen closed 6 days ago

lynn-lumen commented 2 weeks ago

What problem does this solve or what need does it fill?

Currently gizmos.primitive_2d() and gizmos.primitive_3d() require a parameter of type P: PrimitiveNd. Passing &my_primitive is not allowed. This is fine and barely noticeable for primitives that implement Copy but those that don't, like Polygon<N> or BoxedPolyline, need to be cloned every time they are drawn using gizmos (The examples/math/render_primitives avoids this by having all primitives be const).

Some solutions

Since the primitive_Nd functions do not do anything that could not be done with &my_primitive as of now, they could just accept this as a parameter instead. This would obviously cause existing code to be rewritten (gizmos.primitive_2d(PRIMITIVE) -> gizmos.primitive_2d(&PRIMITIVE)) which is rather annoying.

We could introduce a new trait akin to GizmoRefPrimitiveNd<P: PrimitiveNd> with a function primitive_ref_Nd(primitive: &P, ...) that accepts primitives by ref. GizmoRefPrimitiveNd could probably even be implemented automatically for primitives implementing GizmoPrimitiveNd.

If we allow bevy_math to be changed to fix this, we could implement PrimitiveNd for &P where P is some Primitive that does not implement Copy. This would allow implementing GizmoPrimitiveNd<&P>

mweatherley commented 1 week ago

I'm personally of the mind that the primitive_Nd functions should probably just take the primitive argument by reference; I wouldn't be surprised if they were initially conceived under the assumption that primitives would be Copy. That unfortunately breaks existing code, but I think it's the semantically correct approach.

Olle-Lukowski commented 6 days ago

I'll get started on implementing this, probably tomorrow.