3 ms·

I get what you mean, but it seems misleading to cite floating point issues with matrices and call quats lossless. Matrices are not inherently imprecise, they ha

by dahart 2y ago

I get what you mean, but it seems misleading to cite floating point issues with matrices and call quats lossless. Matrices are not inherently imprecise, they have floating point error when you use floating point numbers to represent them, and the same is absolutely true for quats too. A better word than lossless is perhaps ‘overspecified’ when referring to a 3x3 matrix being used to represent a rotation or orientation. A 3x3 matrix has redundant information in that case (however a matrix is more general and more powerful than a quat). But axis-angle is 4D like a quat too, and more intuitive than a quaternion. Actually normalized-axis-angle (with no scaling) can beat normalized quats, because axis-angle can be a 3D value and quats cannot. Same goes for Euler angles too. In general, if your quats are implemented with floats then applying quat transforms will introduce unwanted floating point scaling that may accumulate under repeated operations (and if you compile to a matrix first then you also have the matrix problem you mentioned).

xeonmc 2y ago
1. In this application, floating point drift affect matrices far more than quats. Drifts in quats results in a drifted value of rotation + uniform scaling, but will never introduce deformation. Drifts in matrices may result in total mutilation of your coordinates. The overdetermined nature of matrices with respect to orthogonal transforms means that you lose information about which values constitute the authoritative state, whereas it is by definition impossible for a quat not to be orthogonal even when perturbed with significant error. As an analogy, think of matrices as retained-mode GUI while quats are immediate-mode. 2. Axis angle is just the logarithm of [unit]quats (non-unit quat adds an additional scalar to the axis-angle components). If you want to compose rotations sequentially, you'll still need to take the exponential of axis-angle to turn it into quats. You can author initial state in axis angles as an authoritative declaration of what you meant for the orientation to be, but composing them still invariably requires you to un-logarithm them back to quats, hence what I said about "intermediate representation" 3. I said compile to a matrix at the very end when transforming the final vertices, entirely sidestepping the problem of repeated operations since you're only "baking" it for the final transformation onto vertices.

by dahart 2y ago

xeonmc 2y ago

1. In this application, floating point drift affect matrices far more than quats. Drifts in quats results in a drifted value of rotation + uniform scaling, but will never introduce deformation. Drifts in matrices may result in total mutilation of your coordinates. The overdetermined nature of matrices with respect to orthogonal transforms means that you lose information about which values constitute the authoritative state, whereas it is by definition impossible for a quat not to be orthogonal even when perturbed with significant error. As an analogy, think of matrices as retained-mode GUI while quats are immediate-mode. 2. Axis angle is just the logarithm of [unit]quats (non-unit quat adds an additional scalar to the axis-angle components). If you want to compose rotations sequentially, you'll still need to take the exponential of axis-angle to turn it into quats. You can author initial state in axis angles as an authoritative declaration of what you meant for the orientation to be, but composing them still invariably requires you to un-logarithm them back to quats, hence what I said about "intermediate representation" 3. I said compile to a matrix at the very end when transforming the final vertices, entirely sidestepping the problem of repeated operations since you're only "baking" it for the final transformation onto vertices.