- From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
- Date: Thu, 11 Dec 2008 12:06:37 +0100
- To: www-svg@w3.org

Hello Brian, according to my understanding of SMIL animation, the neutral element for addition for transform scale is indeed 0,0 and not 1,1. This is because if you have a scaling A you get A + (0,0) = (0,0) + A = A. Therefore (0,0) is the identity for addition. The equation is not true, if you use (1,1) instead of (0,0), therefore (1,1) is surely not the identity for addition. There exist constructions with more than one neutral element of addition in mathematics, but this fortunately does not appear within SVG currently ;o) What identity (element) means (especially in english) seems to be confusing here related to matrices. The relevant thing one has to look for, for which operation it results in an identity. For SMIL animation we have to care only about addition. A matrix is called an identity matrix or better unit matrix or in German Einheitsmatrix, if it produces the identity for matrix multiplication. For addition this is called the zero matrix. http://en.wikipedia.org/wiki/Neutral_element animateTransform does not animate matrices themselves, currently not even the type matrix is animatable (unfortunately). It animates numbers, from which later matrices are derived with additional definitions. There is no relation between the animation function and the rules, how to derive the matrix from the numbers. SMIL animation interpolates between the given values with some kind of additive interpolation and does not care about the meaning or later appearance. This ensures, that at least the animations are continous, if the first value is 0 (for cumulative and additive behaviour). That for example a by-animateTransform always starts with a zero scaling is not related to SMIL animation, this is only related to a specific rule for animateTransform, that additive animations (the corresponding matrices) have to be postmultiplied to the underlying value, or alternatively and more precisely, which matrix corresponds to the scale type. If we have the scale(0,0) this is according to SVG the zero matrix. This could have been defined in a more useful way for scaling to avoid different problems, but it is a little bit late now to adjust this. For example if scale(a,b) would represent a matrix matrix(exp(a) 0 0 exp(b) 0 0) this could have avoided the problem for scale animations and the problem to have no inverse for constrained transformations. However, then there is a need again to have an additional operation to mirror an object. The problem with the inverse happens too for skewX/Y if the tangens is infinity and there is a big difference too in animating the skewX/Y values or to animate the related matrices and there is of course a big difference between the addition or accumulation of the skewX/Y values or the postmultiplication or accumulation of the transformations. Therefore for all these animateTransform issues one first has to calculate the complete animation function including cumulation. As a final step one has to care, whether the animation is additive or not. If it is additive, one has to postmultiply the resulting matrix of the animation effect to the underlying value. This specific behaviour is already indicated be the element name animateTransform. Therefore one does not have to care about the meaning of the animated attribute, because the animation effect is calculated independently. I think, for implementors this ensures, that they can have some generic SMIL module to calculate the animation function for all animation issues together. Only for the SVG animateTransform they have to calculate the final presentation value/effect slightly different due to the specific postmultipication rule. There are only a few exceptions. One is implied by the calcMode paced. To achieve the conditions of this mode, one has to know something about the animated attribute or property to get a paced effect. The distance functions depends on the animated attribute/property. This and for which attributes this is applicable is clarified now in SVGT1.2. (This is not interesting for by, from-by, from-to and to animations and for animations with not more than two values in the values list). The second is, that SVG defines, that additive animateTransform has to be postmultiplied instead of added to the underlying value. This is indicated already by the name of the element animateTransform. This has only influence on the final presentation value and how it is derived from the underlying value and the animation effect, but not on the other calculations of the animation function. This causes a currently unsolved problem for continuous to-animateTransform, because it cannot be both the effect as described by SMIL, mainly a smooth change from the underlying value to the to-value, while it is postmultiplied. Another minor (?) problem is a mixture of non interpolable an interpolable values within the animation and for additive animation including the underlying value (this can happen for example for SVG fill and stroke, which are very complex, maybe due to bad design of these attributes; some functionalities should have been separated more carefully, but this is too late now). Obviously those animations cannot be continuous, if such a mixture appears. I think, the animation program has to analyse first the values and the underlying value to decide, whether the calcMode is discrete or continuous (something like this is already indicated within the definition of calcMode). The open problem here is maybe, that animations can end with interactive events, therefore the animation program cannot know always, if the underlying value is something usable for additive animations. Olaf

Received on Thursday, 11 December 2008 11:12:05 UTC