Clarifying from_rotation_ypr

[CAD97]

Mat3, Mat4, and Quat all offer from_rotation_ypr to create the relevant representation of the Tait-Bryan Euler angles. Only Quat actually specifies that here yaw is about Y, pitch is about X, and roll is about Z.

This defines a coordinate system. For this to be correct yaw/pitch/roll, Y is up/down, X is left/right, and Z is forward/back.

Yaw/pitch/roll are coordinate system agnostic, as yaw is rotation about the up/down axis, pitch is rotation about the (transformed) left/right axis, and roll is rotation about the (transformed transformed) forward/back axis. By providing a ypr function that uses yxz, glam is (however slightly) biased toward the coordinate system used there.

We can actually ignore chirality/handedness here, if I understand correctly. A rotation "about Y" is always a rotation from the positive Z axis towards the positive X axis. (Borrowing from geometric algebra, that's why I personally prefer calling it a ZX rotation rather than a Y rotation, but I'm in the great minority here.) Thus if we provide, say, from_rotation_yxz(yaw:pitch:roll:), this specifies the axis rotated and is chirality neutral, as the returned result can by used in either of the two chiralities.

The above is more directly tracked in #79, where the plan seems to be to provide optional common coordinate systems in external crates

---

Separately, it would be great to note the coordinate system assumed by ypr on the other types. Additionally, we should probably specify whether "Euler angles" here refers to "classic Euler" y₀-p₀-r₀ or Tait-Bryan y-p'-r'' (equivalently r_{0-p0-y0. CG tends to exclusively mean Tait-Bryan rather than "proper" Euler angles when they say Euler angles, but it never really hurts to be explicit.}

I would consider this issue closable once all six from_rotation_ypr clarify which axis ypr rotates around and which order the rotations are applied in, though would consider resolving #79 as well sooner rather than later. It definitely is an interesting insight that YPR is chirality-agnostic, though.

[bitshifter]

Just to clarify, you are primarily suggesting renaming from_rotation_ypr to from_rotation_yxz while keeping the parameter names the same?

[bitshifter]

I've updated the comments on the non quat methods. I think it's unlikely that I'll have time to work on #79 any time soon unfortunately.

[bitshifter]

I think this is addressed now by #163. The ypr functions will be deprecated in the next release.

[CAD97]

Yep, #163 addresses my concern here. Sorry for the lack of feedback, I've been busy at grad school; we shipped our game (actual publish pending)!

[bitshifter]

The link didn't work for me, but congratulations on shipping :)