From: Benoit Jacob <jacob.benoit.1@gmail.com>

Date: Fri, 28 Feb 2014 17:07:19 -0500

Message-ID: <CAJTmd9r2s7bOSUM5PCYyRK22n17ExVGuD+6uCLuJACwY1RjDBg@mail.gmail.com>

To: Rik Cabanier <cabanier@gmail.com>

Cc: css3@userks.e4ward.com, "public-fx@w3.org" <public-fx@w3.org>

Date: Fri, 28 Feb 2014 17:07:19 -0500

Message-ID: <CAJTmd9r2s7bOSUM5PCYyRK22n17ExVGuD+6uCLuJACwY1RjDBg@mail.gmail.com>

To: Rik Cabanier <cabanier@gmail.com>

Cc: css3@userks.e4ward.com, "public-fx@w3.org" <public-fx@w3.org>

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 > >Received on Friday, 28 February 2014 22:07:52 UTC

*
This archive was generated by hypermail 2.4.0
: Friday, 17 January 2020 19:49:48 UTC
*