commit a4474491902bcbd62bc9437e0afc5b0a314c33aa
author Kevin Ellis <kevers@chromium.org> Fri Oct 30 20:23:17 2020
committer Blink WPT Bot <blink-w3c-test-autoroller@chromium.org> Fri Oct 30 21:38:09 2020
tree e80990eba2d84f4929ee349f4ad08226d0575f3e
parent a214d8921b82d9b8628c2a3ed31b7f5356b85628

Cleanup quaternion operations for rotation transforms.

The computation of quaternions during matrix decomposition appeared
to be based off of the matrix transpose. Indexing in the quaternion
calculation is consistent with row-major ordering; however, the "rows"
variable is actually column major order (goes back to the original
implementation of unmatrix in Graphics Gems II).  The rotation matrix
constructed from the quaternions also appeared to be assuming row-major
ordering. These discrepancies were mostly corrected for by flipping the
direction of the quaternion when extracting from the matrix.

This patch cleans up the implementation to avoid implicit coordinate
transformations and making the calculations consistent for column-major
ordering in the rotation matrix. Additional comments in the code should
help prevent similar errors in the future.

Combining rotations without a common axis or rotation was needlessly
complex, requiring a conversion to matrices, followed by matrix
blending and rotation extraction from the resulting matrix. In addition
to being computationally expensive, the extra steps reduce numerical
stability and introduce orientation artifacts (the quaternions
(x,y,z,w) and (-x,-y,-z,-w) are effectively equivalent transformations).
The SLERP algorithm in blink::TransformationMatrix and blink::Rotation
now directly call gfx::Quaternion::Slerp. The SLERP algorithm contained
an error in that it always returned the counterclockwise rotation even
if clockwise rotation was shorter.  This problem was fixed by flipping
the orientation of the first quaternion if the half angle is greater
than 90 degrees. This ensures that we take the shortest path.

Test expectation were updated for the rotation-composition test. These
tests recorded expectations based on Blink's evaluations which where not
consistent with the spec.  In particular, Blink short-circuits the
interpolation process at progress 0 and 1. This leads to boundaries
begin left in a non-canonical form (e.g. "1 1 0 45deg" should be
normalized to "0.707 0.707 0 45deg").  Furthermore, transforms to and
from "none" should be converted to a neutral operator based on its
counterpart (e.g none -> rotate 45deg at 0 should be rotate 0deg). One
of the tests contained a degenerate case of a 180 degree rotation which
is ill defined. This test was updated to avoid the problem. We have unit
tests for edge cases to ensure no division-by-zero errors.

One non-WPT test was affected. Manually confirmed that the SLERP
algorithm was computing a negative value for the scalar component
of the quaternion product. This component in fact is the cos of the half
angle.  Since the value was negative, it implies that the rotation angle
was exceeding 180 degrees.  We were rotating in the wrong direction.

Design doc: https://docs.google.com/document/d/1RUd5Nt-ZUnKt-P6OZEDurx9g60TjfD0gx_iYAMbkAfE/edit?usp=sharing
Access via chromium credentials

Bug: 998175, 929841
Change-Id: Iaf057eb576aacfd2029342246ac314d783022997
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2489727
Reviewed-by: Ian Vollick <vollick@chromium.org>
Reviewed-by: Alexander Cooper <alcooper@chromium.org>
Commit-Queue: Kevin Ellis <kevers@chromium.org>
Cr-Commit-Position: refs/heads/master@{#822771}