Skip to content

Conversation

@alanpoon
Copy link

This solution does not need to edit Rapier and parry.
There is talk of creating an External type in Bevy for such situation. bevyengine/bevy#2966
Either way, it is going to cause breaking changes.

pcwalton and others added 9 commits August 29, 2021 20:04
The biggest change here is that doing the same query twice, one mutably and one
immutably, is no longer needed, once bevyengine/bevy#2305 lands. Before that
lands, however, this upgrade is actually impossible to do safely, since the
`q0`/`q0_mut` distinction is gone and therefore it's impossible to implement
the Rapier component traits on Bevy queries. (This is filed upstream as
bevyengine/bevy#2744.) Therefore, this upgrade has to wait until that Bevy PR
lands.

Other minor changes:

* `Light` has been renamed to `PointLight`.

* `App::build()` is now `App::new()`, and `AppBuilder` is now `App`.

* `glam` has been upgraded upstream.
@sebcrozet
Copy link
Member

Thank you for this PR @alanpoon. I think this is the right approach for now. Modifying Rapier and Parry to add the Component impls is a bit too intrusive, and isn’t future proof since it won’t allow us to implement Reflect for these types. So I am going to start with wrapper types for now, and see how we can improve this further by defining our own bevy-idiomatic components (based on glam and bevy types) that would synchronize with Rapier’s components.

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

Successfully merging this pull request may close these issues.

3 participants