Re: [css-transforms] matrix interpolation

2014-02-28 15:41 GMT-05:00 Benoit Jacob <jacob.benoit.1@gmail.com>:

>
>
>
> 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.
>
> I'm glad to hear that transform interpolation will not always resort to
> matrix interpolation, but I am talking about matrix interpolation here.
>
> I don't believe that the case of matrix interpolation is rare at all:
>
>  - 1. It is not uncommon for authors to rely on the parts of the CSS
> Transformations spec that allows them to specify transforms as matrices;
>
>  - 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. 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.
>

Scrap that, I am told offline that representing transforms as such lists of
primitive transforms is quite traditional and that people rely on it for
specific reasons, and in particular, that polar decomposition by itself
couldn't interpolate skews in the intuitive way. So I understand (now) that
matrix interpolation has to be a last resort. I would maintain, though,
that it can't be rare especially as the spec allows specifying transforms
as matrices, and anyhow, the spec has to allow for matrix interpolation, so
we have to find a solution to this problem.

Benoit




>
> 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
>>>>
>>>>
>>>>
>>>>
>>>
>>
>

Received on Friday, 28 February 2014 21:30:27 UTC