Re: [css-transforms] matrix interpolation

2014-02-28 16:36 GMT-05:00 Rik Cabanier <cabanier@gmail.com>:

>
>
>
> On Fri, Feb 28, 2014 at 12:41 PM, Benoit Jacob <jacob.benoit.1@gmail.com>wrote:
>
>>
>>
>>
>> 2014-02-28 15:17 GMT-05:00 Rik Cabanier <cabanier@gmail.com>:
>>
>>
>>>
>>>
>>> On Fri, Feb 28, 2014 at 10:17 AM, Benoit Jacob <jacob.benoit.1@gmail.com
>>> > wrote:
>>>
>>>> As a coincidence, I just wrote to this mailing list to make the same
>>>> complaint and suggestion,
>>>> http://lists.w3.org/Archives/Public/public-fx/2014JanMar/0084.html
>>>>
>>>> I've put up a demo underlining the problems with the current spec's
>>>> mandated interpolation algorithm, see here:
>>>> http://people.mozilla.org/~bjacob/transform-animation-not-covariant.html
>>>>
>>>
>>> From your web page:
>>>
>>> the CSS Transforms spec<http://dev.w3.org/csswg/css-transforms/#matrix-interpolation>mandates matrix interpolation to be performed is not
>>> coordinate-independent, i.e. isn't an interpolation of just the geometric
>>> transformations but rather an interpolation of quantities that depend on
>>> the coordinate system,
>>>
>>>
>>> That is not corrrect. Interpolation happens on the specified transform
>>> functions. see:
>>> http://dev.w3.org/csswg/css-transforms/#interpolation-of-transforms
>>> Matrix interpolation will only happen if you specify a matrix which will
>>> happen very rarely or if there's a mismatch of transform functions (which
>>> is likely a user error)
>>>
>>
>> The excerpt of my page which you quote above does say that the spec
>> mandates _matrix_ interpolation to be performed in this way; given the
>> presense of the word "matrix" here, I don't see how to make this sentence
>> more clear, but would welcome suggestions.
>>
>
> the following snippet is confusing:
>
> "an interpolation of quantities that depend on the coordinate system"
>
>
> It implies that it's the current transformation matrix (which is the
> concatenation of all transform upto that point) that is interpolated.
> Is that what you mean?
>

Yes, and so yes my complaint is specific to matrix interpolation.


>
>
>>  - 2. I don't believe that a "mismatch" of transformations is likely to
>> be a user error; it is reasonable for authors to wish to interpolate
>> between two arbitrary transforms without having to worry about how to
>> specify them both as the same sequence of elementary transforms;
>>
> That the spec requires storing a list of primitive transforms and
>> interpolating,
>> http://dev.w3.org/csswg/css-transforms/#interpolation-of-transforms , is
>> actually the next aspect of the spec that I would like to question. For one
>> thing, it means that the interpolation depends not only on the geometric
>> transformations at hand, but really depends on how these geometric
>> transformations are specified as particular choices of lists of primitive
>> transformations. I would like the interpolation to only depend on the
>> geometric transformations, not on any abstract consideration of how
>> transformations are specified.
>>
>
> No, the transform functions should not be collapsed into a single matrix.
> Take for instance:
>
> #b { transform: scale(.1, 1) rotate(0);}
> #b:hover { transform: scale(1) rotate(90deg);}
>
>
> By collapsing this into a matrix, you would lose the fact that the scale
> happens first, followed by a rotate. [1]
> The polar decomposition always assumes that rotate happens first, followed
> by a scale.
>

[ Side note: There is 1 bit of freedom in polar decomposition: you can
decompose into Rotation*Scaling or into Scaling*Rotation. In the present
discussion, let's say that a polar decomposition interpolation
implementation has settled on Rotation*Scaling, as assumed in your above
sentence. ]

Let's say that you have a scaling, S, and a rotation, R.

You take the product S*R as above, and ask, what is its polar decomposition
as Rotation*Scaling?

It goes like this. Let Rt denote the transpose of R, which is also the
inverse of R since R is a rotation, so we have R*Rt == Rt*R == Identity, so

S * R
  = Identity * S * R
  = (R * Rt) * S * R
  = R * (Rt * S * R)

Let T = Rt * S * R. We then have:

S * R = R * T       (1)

and notice that T is just S conjugated by R i.e. T is a scaling, namely the
scaling obtained by taking S and applying the rotation Rt to its scaling
axes.

That equation (1) is the polar decomposition of S * R.

In other words, polar decomposition should work nicely with transformations
of the form scaling * rotation.

But, see my previous email, I am no longer advocating for matrix
interpolation as the only interpolation that we ever need, because I've
been convinced offline that there is a world out there that relies on
specific interpolation behavior that is not achievable by polar
decomposition interpolation, such as interpolating skews intuitively.

Benoit



>
>
>
>> Polar decomposition would give us that, and remove much of the need to
>> specify lists of separate transforms to interpolate. If authors want finer
>> control on the interpolation, then they already have a tool for that:
>> adding more keyframes. If that is still not enough, and that feature is
>> deemed worth addressing, then we can talk about it; but the current
>> list-of-transforms-to-interpolate-separately approach seems like an attempt
>> to wallpaper over the deficiencies of the currently mandated matrix
>> interpolation method.
>>
>> Benoit
>>
>>
>>>
>>> I even linked to your article, which turned up as the first google
>>>> search result for "polar decomposition animation" !
>>>>
>>>> Here's hoping that we can get a polar-decomposition-based solution
>>>> accepted...
>>>>
>>>
>>> Would it be possible to create a test page that shows the results of
>>> this decomposition?
>>> I created a sample page here:
>>> http://jsfiddle.net/cabanier/Vv84m/embedded/result/ that shows some
>>> common interpolations.
>>> Safari is the only one that implements the current spec and has the most
>>> intuitive behavior. It would be good if we could see what animations using
>>> polar decomposition would look like.
>>>
>>>  2014-01-08 12:17 GMT-05:00 <css3@userks.e4ward.com>:
>>>>
>>>> Greetings.
>>>>>
>>>>> It is delightful to see 3D capabilities coming to CSS styling.
>>>>>
>>>>> It is disappointing to see the choice for matrix interpolation.
>>>>>
>>>>> Specifically, I'm looking at Section 20: Interpolation of matrices.
>>>>>
>>>>>   <http://www.w3.org/TR/css3-transforms/#matrix-interpolation>
>>>>>
>>>>> The draft standard specifies using a method found in Graphics Gems II,
>>>>> edited by Jim Arvo.
>>>>>
>>>>> However, in 1992 I published a paper with Tom Duff, entitled "Matrix
>>>>> Animation and Polar Decomposition", which has important advantages set
>>>>> out there.
>>>>>
>>>>>   <http://academic.research.microsoft.com/Paper/371892.aspx>
>>>>>
>>>>> For those who do not know the 3D computer graphics literature well, Tom
>>>>> Duff (now at Pixar) has two Academy awards for technical contributions,
>>>>> and I introduced quaternion animation to computer graphics. So perhaps
>>>>> our ideas our worth considering.
>>>>>
>>>>> And if you had only looked at Graphics Gems IV, you would have found my
>>>>> "Polar Matrix Decomposition" on pages 207 through 221, complete with
>>>>> implementation code!
>>>>>
>>>>>   <http://tog.acm.org/resources/GraphicsGems/gemsiv/polar_decomp/>
>>>>>
>>>>>
>>>>>
>>>>> We didn't have any special insight into meaningful ways to deal with
>>>>> perspective elements in a general (4x4) matrix transform, so we
>>>>> improvised for that. Translation is, of course, trivial to split off
>>>>> from an affine transform. So the heart of the paper is how best to
>>>>> split
>>>>> a (3x3) linear transform into meaningful primitives.
>>>>>
>>>>> I have great respect for Spencer Thomas, who wrote "unmatrix"; nor is
>>>>> he
>>>>> the only one to have taken a stab at this puzzle. Animating matrices is
>>>>> generally a method of last resort, and part of the problem is what
>>>>> constitutes a good solution.
>>>>>
>>>>> We claim that a lesser-known numerical analysis split known as the
>>>>> Polar
>>>>> Decomposition has a number of advantages over prior efforts, including
>>>>> an explicit criterion for a good solution.
>>>>>
>>>>> For purposes of CSS transforms, note that it is trivial to compute the
>>>>> Polar Decomposition of a 2x2 matrix. (The original paper explains how.)
>>>>>
>>>>> Since the paper was written, numerical analysts have found even more
>>>>> clever ways to do the split in higher dimensions; 3x3 matrices require
>>>>> little work even with a simple Newton iteration.
>>>>>
>>>>>   Q_{0} = M
>>>>>   Q_{i+1} = ( Q_{i} + Q_{i}^{-T} ) / 2
>>>>>
>>>>> That is, we set Q to the 3x3 matrix M, and repeatedly average Q with
>>>>> its
>>>>> inverse transpose to converge Q to an orthogonal matrix.
>>>>>
>>>>> A non-singular matrix M has a unique nearest orthogonal matrix, which
>>>>> is
>>>>> precisely what we will get -- and what we want. (See the paper.)
>>>>>
>>>>> Having cleanly split off M's rotation part (possibly with a negation)
>>>>> as
>>>>> Q, what remains is purely scaling.
>>>>>
>>>>>   S = Q^{T} M
>>>>>
>>>>> It is unrealistic to expect S to be diagonal; Polar Decomposition is
>>>>> "physical", essentially independent of coordinate system. So S will in
>>>>> general take the form it must when the scaling axes are not the same as
>>>>> the matrix axes: it will be symmetric and non-negative definite.
>>>>>
>>>>> The paper lays out the options and implications for animation once we
>>>>> have the split.
>>>>>
>>>>>
>>>>>
>>>>> If you have already considered and discarded Polar Decomposition, my
>>>>> apologies. If not, I urge you to try it.
>>>>>
>>>>>  -- Ken Shoemake
>>>>>
>>>>>
> 1: http://codepen.io/adobe/pen/foLud
>
>