Closed janhohenheim closed 5 months ago
Could Reflect
just be implemented directly (manually) on the wrapper types defined by bevy_rapier
instead of having to be propagated down to rapier
(and, most likely, parry
)?
There is no plan to add a Reflect
derive to rapier
since that would also require such feature on parry
, and nalgebra
. We should have Reflect
implemented manually in bevy_rapier
types instead.
Thanks for the update! I can understand that you don't want to propagate the feature everywhere :)
Just FYI, last time I checked (1 year ago), this was hard to do properly as the underlying types inside the wrappers did not derive Reflect
and such would require quite a bit of boilerplate.
Alternatively, there is a PR in the works in Bevy that allows deriving Reflect
on foreign types by redefining them and then deriving Reflect
on these dummy types. You can do that, just be aware that this means duplicating many parry
types for bevy_rapier
.
Thank you for the info! We’ll keep an eye on this. Hopefully we can work something out at the bevy_rapier
level eventually.
Currently,
bevy_rapier
can (de facto) not be used in tandem with bevy dynamic scenes, since colliders cannot be serialized due to not beingReflect
. This means that save systems that would like to use the built-in bevy scene format need to clutter the graph with marker traits for which colliders were spawned how, which defeats the purpose of the dynamic scene as "just dump the entire world into a file and don't worry about it". Additionally, colliders cannot be inspected at runtime in editors, which is a pity if generating them dynamically.I propose adding an optional
bevy_reflect
feature to rapier that only derivesReflect
andFromReflect
for the types that aren't inbevy_rapier
and then add them to the type registry throughbevy_rapier
.If I get your okay @sebcrozet, I'll do this myself.