`ang_vel.to_radians()` is a footgun about bevy_xpbd HOT 3 CLOSED

I guess one workaround would be to just add documentation comments that specify that AngVel (and other angular components) use radians, and hope that users understand not to use to_radians. If we want to be more explicit, we can specifically mention that to_radians probably won't do what you expect, since it's already in radians.

Something like this:

/// The angular velocity of a body, expressed in radians.
///
/// **Note**: Because the component's value is already in radians, calling the derived method `to_radians` will probably not produce the expected result.
#[cfg(feature = "2d")]
#[derive(Reflect, Clone, Copy, Component, Debug, Default, Deref, DerefMut, PartialEq, From)]
#[reflect(Component)]
pub struct AngVel(pub f32);

Like you said, we could also just remove Deref, at least from the components that use radians, but I wouldn't remove it from every component because of ergonomics. Removing it from just a few components would reduce consistency though...

from bevy_xpbd.

Yeah, the reason it's particularly tempting is that we have Rot::from_radians, so it's particularly tempting to try to call through your IDE's auto-completion, and I don't think warnings in the reference would help much then.

e.g. this fails:

let rot = Rot::from_radians(PI);
assert_relative_eq!(PI, rot.to_radians());

I think removing the deref impl would probably be best here... but let's maybe wait and see a bit.

from bevy_xpbd.

For now I'll just remove the Deref impl from the 2D AngularVelocity (see #46). I agree that it's probably the best way to go about this.

If someone has a better approach, feel free to reopen this issue.

from bevy_xpbd.