Re: [css3-transforms] neutral element for addition - by animation

On Jun 2, 2012, at 11:02 AM, Dr. Olaf Hoffmann wrote:

> Dirk Schulze:
> 
> ...
>> 
>>> For the operation of addition of matrices M:  0:=scale(0,0) represents
>>> a neutral element M = M + 0 = 0 + M, but typically this is not very
>>> important for transformations in SVG or CSS.
>> 
>> I added a first draft of  the definition for the 'neutral element of
>> addition' to CSS Transforms [1]. The only problem that I see is with
>> 'matrix', 'matrix3d' and 'perspective'. According to the definition of SMIL
>> the values should be 0 (list of 0) as well. This would be a non-invertible
>> matrix for 'matrix' and 'matrix3d' 
> 
> This applies as well for scale(0,0), scale(0,y), scale(x,0) etc, 
> therefore no really new problem.
No. As long as the third (and second) rule of [1] apply to the transform function list, these transform functions can get interpolated numerically, as described by [2].

> I got the impression from the previous discussion, that this quaternion
> approach could avoid the nasty problem of matrix inversion, but still
> the related section contains such nasty implications, which cause
> such problems.
The quaternions try to solve other problems like the Gimbal Lock, a side product of the decomposing of matrices. A problem that can occur with euler angels.


> As long as this is not stabilised by avoiding inversions,
It is unclear to me what "stabilized" means for you :)

> such problems will remain - mainly with the funny effect of 
> surprising discontinuities in animations for authors 
> (maybe CSS using authors can work around this in some cases 
> with a 'rotation' with infinitesimal radius and size around the '0', 
> as long as nothing better is implemented/available, but this
> requires more manual computation of the timing (keytimes)
> by the author ;o) 
> 
>> and a undefined matrix for 
>> 'perspective'. 
> 
> With the few tests (CSS+XHTML) I made related to perspective with 
> viewers available for me, I could not see an effect anyway, this was
> even worse than for other 3D effects. 
> 
> But obviously looking at the matrix in 21 it represents, 0 would be
> indeed interesting ;o)
> 
> On the other hand - currently it is not yet defined, how to apply
> such matrices at all to get a perspective view - maybe it is
> an approach to change this matrix and use a respectively 
> modified formula ;o)
There is a whole section in the spec [4] that describe how to apply perspective and how to multiply nested transformation functions. In general they try to specify the current behavior of current browsers. 

> As long as the behaviour is not defined,
> there is nothing to discuss or to implement for 3D transforms ;o)
> In doubt, indeed one has to define a specific rule once it is
> defined, how such 3D-matrices are applied.
> But looking on the matrices, implicating already some
> concept, my assumption is, one cannot avoid a problem
> here.
3D transforms are already implemented. The current behavior needs to be specified now.

> 
> Due to the graphs in 6.1. d="0" means, that the eye of
> the observer sticks into the canvas/object or vice versa - 
> one cannot expect a meaningful behaviour for this. 
> Because for the perspective property with similar meaning 
> it is already mentioned, that the length must be positive,
> one just has to define what to do for a not positive
> value - automatically one gets the correct behaviour,
> if this appears in an animation, including the result of 
> a by-animation of perspective - I think, it will apply for
> the property and the transform type.
> 
>> The interpolation chapter for matrices does not allow 
>> interpolation with non-invertible matrices [2]. 
> 
> Well, this is not nice. I think, Opera has implemented this for
> years already for matrix and I did some simulations with an 
> animation of xlink:href of a use element with about 20 references
> a second, and of course, there is no visual problem at 0 - it happens
> only, what can be expected - everything is reduced to an (invisible) dot.
I have not checked additive transform behavior on matrices for SVG Animations on Opera so far. At least for CSS Transforms start and end matrix must be invertible, otherwise the interpolation does not work.

> It causes no problem to apply such matrices without animation to 
> arbitrary content, therefore it can be expected, that an animation
> method is chosen, that does not introduce problems in areas, where
> are no problems. Fortunately we know already a method, that causes
> no such additional problem. This is described in SMIL. Of course, 
> there can be others as well.
If you tested additive matrix interpolations on SVG Animations with Opera, and if it gave you a smooth interpolation, then maybe because every value of the matrix got interpolated numerically. Like I said, I did not check it myself. However, for CSS Transforms it was decided, that this 'mostly' does not give you reasonable results. Therefore CSS Transforms uses decomposing. The decomposing code in current browsers can not deal with  non-invertible matrices.

> 
> And I think, to apply this CSS specific decompostion method
> to a SMIL animation with animateTransform, one needs to
> specify another calcMode anyway. Maybe one should add
> a new calcMode 'complex' to get this effect - if needed at all
> for animateTransform.
> For the currently available methods one simply has to interpolate 
> between the list values without a need for inversions or 
> decompositions and problems resulting from this - 
> especially for matrix this it pretty useful, to get stable and
> predictable effects for numerical calculated approximations
> of transform effects. Presumable with only the CSS specific
> and instable decomposition method it is better for this use
> case to continue to simulate the effect with an 
> animation of xlink:href of a use element with about 20 
> references a second.
> 
>> Therefore 'by' animations
>> on these transform functions will fall back to discrete animations and
>> cause the element not to be displayed for half of the animation [3].
> 
> This is another indication, that such a decomposition approach would be
> instable, not suited to daily/serious use and not useful/meaningful for 
> (additive) animateTransform at all.
For daily serious use you would use transform functions that are interpolatable by [2]. These animations make most sense, give you reasonable results and fulfill >90% of all use cases.

> 
> 
> Olaf
> 

Greetings,
Dirk

[1] http://dev.w3.org/csswg/css3-transforms/#animation
[2] http://dev.w3.org/csswg/css3-transforms/#interpolation-of-transform-functions
[3] http://en.wikipedia.org/wiki/Gimbal_lock
[4] http://dev.w3.org/csswg/css3-transforms/#transform-rendering

Received on Saturday, 2 June 2012 22:22:27 UTC