rapier 0.20 feature: RevoluteJoint::angle
#530
Conversation
…ded from rapier 0.20.
…ecify a lot of systems/filters the generic path could be interesting when/if bevy supports trait queries, but currently I feel it's not worth it.
| /// according to its [`RevoluteJoint`] description. | ||
| /// | ||
| /// Parameter `entity` should have a [`ImpulseJoint`] or [`MultibodyJoint`] component with a [`JointDescription::RevoluteJoint`] variant as `data`. | ||
| pub fn angle_for_entity_impulse_revolute_joint(&self, entity: Entity) -> Option<f32> { |
There was a problem hiding this comment.
Perhaps this could be named impulse_revolute_joint_angle (even if it takes an Entity)?
There was a problem hiding this comment.
My objective was to insist on the requisite for given entity to be a ImpulseJoint, but I'm ok with shortening it.
Looking at this makes me realize the documentation comment is wrong, I couldn't make this work with multibodyjoint: as multibodyjoints have multiple bodies, the same API cannot really be applied (if I understand correctly)
| impl JointDescription { | ||
| /// The underlying generic joint. | ||
| pub fn generic_joint(&self) -> &GenericJoint { | ||
| match self { | ||
| JointDescription::FixedJoint(j) => &j.data, | ||
| JointDescription::GenericJoint(j) => j, | ||
| JointDescription::PrismaticJoint(j) => &j.data, | ||
| JointDescription::RevoluteJoint(j) => j.data(), | ||
| JointDescription::RopeJoint(j) => j.data(), | ||
| #[cfg(feature = "dim3")] | ||
| JointDescription::SphericalJoint(j) => j.data(), | ||
| JointDescription::SpringJoint(j) => j.data(), | ||
| } | ||
| } | ||
| /// The underlying generic joint. | ||
| pub fn generic_joint_mut(&mut self) -> &mut GenericJoint { | ||
| match self { | ||
| JointDescription::FixedJoint(ref mut j) => &mut j.data, | ||
| JointDescription::GenericJoint(ref mut j) => j, | ||
| JointDescription::PrismaticJoint(ref mut j) => &mut j.data, | ||
| JointDescription::RevoluteJoint(ref mut j) => &mut j.data, | ||
| JointDescription::RopeJoint(ref mut j) => &mut j.data, | ||
| #[cfg(feature = "dim3")] | ||
| JointDescription::SphericalJoint(ref mut j) => &mut j.data, | ||
| JointDescription::SpringJoint(ref mut j) => &mut j.data, | ||
| } | ||
| } | ||
| } |
There was a problem hiding this comment.
These could be AsRef/AsMut implementations instead.
There was a problem hiding this comment.
true, I'll do that.
For the story behind this explicit naming: ideally I would have liked to wrap our joints (bevy_rapier::FixedJoint, etc...) around the correct joint from rapier (rapier::FixedJoint, etc.), so a user could use the relevant functions from rapier if some functions were not exposed by bevy_rapier (it can easily be forgotten...), but I had difficulties, probably the builder had to be updated significantly so I dropped the idea.
See #529 for similar reasoning logic.
Co-authored-by: Sébastien Crozet <sebastien@crozet.re>
add helper method to get the angle of a revolute joint ; from rapier 0.20.
We noticed a bug on joints because of rapier 0.20, so this builds up on #547.
I wanted to take the
ImpulseJointSetas parameter but that doesn't work withMultibodyJointSetso I settled to pass rigidbodies.I tried to implement a Generic
ImpulseJoint<JointDescription>, but that proved very impractical for functions such assync removal. we could revisit that if one day bevy supports trait queries, but currently I feel it's not worth it.Because we need both
ImpulseJointandRevoluteJointfromRapierContext, I couldn't settle on a better place thanRapierContextfor thisangle_for_entity_impulse_revolute_jointfunction.Failed improvements
I would have liked to make it more typed, but that's the best I could do.
I think it boils down to
bevy_rapier::ImpulseJointnot exposing directlybody1andbody2, which are necessary to compute the angle. I imagine it's current entity +bevy_rapier::ImpulseJoint::parent, but I went the route to get the data from rapier directly, it doesn't complicate the public facing API.I feel a method
angle(entity, entity)would only be more difficult to follow invariants.