-
Notifications
You must be signed in to change notification settings - Fork 157
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
Unnecessary handedness in rotation explanation #78
Comments
Ah right, handedness has confused me a bit at points. I guess looking at https://www.evl.uic.edu/ralph/508S98/coordinates.html it's more about the convention than what is going on in the math. |
If you felt like rewording it I'd be happy to accept a PR. Otherwise I will get to it sometime. |
For what it's worth, I found the documentation helpful and hope that it's not removed. Wouldn't the angles need to be negated if the rotations were following the right-hand rule? |
I don't think so, only for a function like I think that is what @emilk was getting at. Code wise: use glam::{Mat3, Vec3};
// rotate +z 90 degrees around y giving +x
let m = Mat3::from_rotation_y(90.0_f32.to_radians());
let v = m * Vec3::unit_z();
assert!(v.abs_diff_eq(Vec3::unit_x(), core::f32::EPSILON)); |
Thanks @bitshifter ! |
In the landing page of the documentation at https://docs.rs/glam you can read the following:
Then follows his code:
The thing is: quarternion rotations are not tied to any frame or handedness. For left-handed coordinate systems it follows left-hand rule, and for right-handed coordinate systems it follows right-hand rule. Consider a right handed X-Y-Z system. 90 deg rotation around Y would bring +X to the -Z direction, just like the example above.
So the above paragraph muddies the waters and may unnecessarily scare away people who use right-handed systems.
SUMMARY: glam is (mostly) handedness agnostic. I think it would help the project to say so up-front, instead of implying the opposite!
The text was updated successfully, but these errors were encountered: