Re: [css-transforms] matrix interpolation

On Feb 28, 2014, at 10:36 PM, Rik Cabanier <cabanier@gmail.com> wrote:

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

The current transformation matrix is just the transformation from the elements coordinate space to the parent element coordinate space, not the concatenation of all transforms. Or do you mean all transforms of the current transform function list of the current element? That would be correct.

Greetings,
Dirk

> Is that what you mean? 
> 
> 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;
> 
> Sure, but do they rely matrix interpolation for CSS animations and transitions? 
> Since we have currently have 3 different algorithms and few if any users are complaining, I would find it hard to believe that this is very common.
>  
>  - 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.
> 
>  
> 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 
>

Received on Friday, 28 February 2014 22:23:36 UTC