Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add optional bevy feature for reflection #467

Closed
janhohenheim opened this issue Mar 18, 2023 · 4 comments
Closed

Add optional bevy feature for reflection #467

janhohenheim opened this issue Mar 18, 2023 · 4 comments

Comments

@janhohenheim
Copy link
Contributor

Currently, bevy_rapier can (de facto) not be used in tandem with bevy dynamic scenes, since colliders cannot be serialized due to not being Reflect. 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 derives Reflect and FromReflect for the types that aren't in bevy_rapier and then add them to the type registry through bevy_rapier.

If I get your okay @sebcrozet, I'll do this myself.

@sebcrozet
Copy link
Member

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)?

@sebcrozet
Copy link
Member

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.

@sebcrozet sebcrozet closed this as not planned Won't fix, can't repro, duplicate, stale Mar 23, 2024
@janhohenheim
Copy link
Contributor Author

janhohenheim commented Mar 23, 2024

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.

@sebcrozet
Copy link
Member

Thank you for the info! We’ll keep an eye on this. Hopefully we can work something out at the bevy_rapier level eventually.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants