The formulas provided for quat to matrix and quat to axis angle is terrible, they only work if the quaternion's magnitude is exactly one. You need to replace sqrt(1 - a*a) assumptions with actual components, and use atan2 instead of acos. I don't blame the author though because the vast majority of info you can find in online learning materials uses this ill-advised formulation, including Wikipedia. But it's really trivial to realize this fact if you just go ahead and derive from the quat sandwich from first principles and realize that the "convenience simplification assuming unit quat" is actually an unnecessary step that have no benefits and are wholly detrimental when implementing them for floating point numbers.
> they only work if the quaternion's magnitude is exactly one
That's why you always normalize the quaternion first, and the article seems to require the normalized form:
Q.54 How do I convert a quaternion to a rotation matrix?
Assuming that a quaternion has been created in the form:
Q = |X Y Z W|
At least, I would read |X Y Z W| as meaning normalized(X Y Z W)
I don't see this notation explicitly defined when they describe quaternion normalization (Q.52) though, so I agree this leaves much out. It's more a cheat sheet than learning material.
> You need to replace sqrt(1 - a*a) assumptions with actual components, and use atan2 instead of acos
I'm kind of rusty with this, but I think the reason we don't do that is that it's cheaper to normalize then convert rather than use the non-normalized conversion formula. Correct me if I'm wrong.
> That's why you always normalize the quaternion first
Again, that won't solve the problem of floating point components not perfectly adding up to one.
Constantly normalizing quats are unnecessary performance hits and worsens your accuracy with no benefit other than being marginally "easier for low-math programmers to reason about", when you could instead just work with non-unit quats homogeneously and divide the final result with the quat square magnitude just once in the entire pipeline, or not at all and instead just pass the square magnitude as your w factor that gets divided on the GPU anyways
If you need this stuff in production I recommend getting a good computer graphics textbook.
These cheat sheets are convenient _if you already know what you are doing_ and _are confident the cheat sheet uses same presentation as your problem domain_.
That said I'm not sure if there is a nice book that would be both exact and practical at the same time.
The formulas provided for quat to matrix and quat to axis angle is terrible, they only work if the quaternion's magnitude is exactly one. You need to replace sqrt(1 - a*a) assumptions with actual components, and use atan2 instead of acos. I don't blame the author though because the vast majority of info you can find in online learning materials uses this ill-advised formulation, including Wikipedia. But it's really trivial to realize this fact if you just go ahead and derive from the quat sandwich from first principles and realize that the "convenience simplification assuming unit quat" is actually an unnecessary step that have no benefits and are wholly detrimental when implementing them for floating point numbers.
> they only work if the quaternion's magnitude is exactly one
That's why you always normalize the quaternion first, and the article seems to require the normalized form:
Q.54 How do I convert a quaternion to a rotation matrix?
Assuming that a quaternion has been created in the form:
Q = |X Y Z W|
At least, I would read |X Y Z W| as meaning normalized(X Y Z W)
I don't see this notation explicitly defined when they describe quaternion normalization (Q.52) though, so I agree this leaves much out. It's more a cheat sheet than learning material.
> You need to replace sqrt(1 - a*a) assumptions with actual components, and use atan2 instead of acos
I'm kind of rusty with this, but I think the reason we don't do that is that it's cheaper to normalize then convert rather than use the non-normalized conversion formula. Correct me if I'm wrong.
> That's why you always normalize the quaternion first
Again, that won't solve the problem of floating point components not perfectly adding up to one.
Constantly normalizing quats are unnecessary performance hits and worsens your accuracy with no benefit other than being marginally "easier for low-math programmers to reason about", when you could instead just work with non-unit quats homogeneously and divide the final result with the quat square magnitude just once in the entire pipeline, or not at all and instead just pass the square magnitude as your w factor that gets divided on the GPU anyways
Graphics programmers use “quaternion” as a shorthand for “unit quaternion.”
Also, I really think we'd all be better off if we stopped using quaternions entirely and started using rotors instead.
They're pretty much the same thing except in one of them you say "i, j, k" and in the other you say "e12, e13, e23".
In the other, you say "xy, yz, zx" (or whatnot), which makes it much clearer as to what's what.
What exactly does `i` correspond to in a quaternion? They always rely on implicit assumptions/conventions.
If you need this stuff in production I recommend getting a good computer graphics textbook.
These cheat sheets are convenient _if you already know what you are doing_ and _are confident the cheat sheet uses same presentation as your problem domain_.
That said I'm not sure if there is a nice book that would be both exact and practical at the same time.