Re: animateTransform & matrix


Thanks for your quick answer.

I would strongly suggest to rethink and discuss this
point for future specifications (and maybe get some
advice from a mathematician affiliated with W3C). If
possible "singularities" are the only reason, then,
why should the animation for scale from 1 to -1, or
even worse from 1,1 to -1,-1 be allowed? Simply,
because they make geometrical sense. In the same way
any path (including any parametrization) of
transformation matrices can make sense to some people
(while it does not seem necessary or sensible to

Think of somebody trying to visualize (in 2D) turning
a page (viewed not from top (scale) or the side
(rotate), but e.g. from a 45 degree angle).

A different animation, corresponding to the straight
line path (with constant speed) of transformation
matrices can be easily understood geometrically: each
point in an object (transformed by the first matrix)
follows a straight line (with constant speed) to the
image under the transformation by the second matrix.

It is simply not true, that most animations can be
constructed by sums of animations for primitive
transformations. Just try constructing one of the
above examples of animations (in all generality) using
animated sums of primitive transformation. While any
transformation matrix can be easily decomposed (in
several different ways) into primitive
transformations, doing that for the whole animation
(i.e. taking into account all times), is much more
difficult if not impossible. One big problem is, that
you cannot control the parametrization for the

Even if it is possible to find such a decomposition of
animations, it would be very inefficient for a large
number of animations being done at the same time. The
only option, a person trying to animate one of the
above examples in SVG has, to manually find the
transformation for each frame.

In any case, having the option of choosing any path of
transformation matrices (including its
parametrization), would be extremely useful and would
make life so a lot easier. I do not believe, it is
much harder to implement this than it is to implement
primitive animations (rotation, skew, translation).
SVG has a big potential as a tool for mathematicians
(especially geometers). But without generalizing the
specification for animation, the animation part of SVG
will not suffice.

A possible way to define parametrizations could be
<animateTransform attributeName="transform"
attributeType="XML" type="matrix"
path="1-t,t^2,t^2,1-t,5t+3,2t-1" from="0" to="1"
dur="5s" additive=
"sum" fill="freeze"/>

meaning you follow this path of transformation
matrices from t=0 to t=1 with constant speed and
duration 5 seconds. This would make a lot of people
happy. Implementing this, would take some thought, but
should be straightforward. (Already allowing
polynomials would be great. Allowing other functions,
like trigonometric functions and others, would be even

On a slightly different note, it does not become clear
from the specification, how the animation is
parametrized. Especially for sums, the parametrization
is crucial. The parameters (e.g. the angle in case of
rotation or skewing) for the transformations change
linearly with respect to time, correct? (But would it
not be great to allow arbitrary parametrizations...)

Benjamin Himpel

--- Dean Jackson <> wrote:
> Benjamin,
> I asked Jon Ferraiolo, the editor of the SVG 1.0
> specification
> for the answer, since I couldn't remember. Here is
> his answer:
> If you allow animation of an arbitrary matrix to
> another arbitrary matrix,
> there is a chance you can reach a singularity midway
> through the animation.
> To avoid this, we restricted animateTransform to
> specify a single type of 
> transform (i.e., scale vs. rotate vs. translate
> etc.). A content develop
> can still achieve arbitrary matrix transforms via
> the 'additive' feature    
> for animateTransform (where additive in this case
> actually means matrix    
> multiplication).
> Dean
> On Sun, 19 Jan 2003, Benjamin Himpel wrote:
> > 
> > Hi,
> > 
> > Why can one not use animateTransform together with
> > matrix? Why does the specification not allow
> > expressions like the following?
> > 
> > <animateTransform attributeName="transform"
> > attributeType="XML"
> > type="matrix" from="1,0,0,1,0,0" to="2,3,1,2,1,1"
> > dur="5s"
> > additive="sum" fill="freeze"/>
> > 
> > One could simply define this to be the animation,
> > which follows the straight line between the two
> > transformation matrices with constant speed.
> > 
> > I found the following excerpt in some newsgroup,
> but
> > do not remember which:
> > 
> > "Because of mathematical issues, we couldn't allow
> > arbitrary matrics to be part of the animation
> values.
> > You can only animate primitive operations such as
> > rotate, scale or translate. But you can define
> > additive 'animateTransform' animations on the same
> > 'transform' attribute in such a way that you can
> > achieve most arbitrary matrix effects.
> > 
> > Bottom line - you should be able to do just about
> > everything you can do with a matrix using some
> > combination of 'animateTransform' animations."
> > 
> > I do not understand, what mathematical issues
> would
> > relevant here. As matter of fact mathematicians
> would
> > not mind to simply specify the path (including its
> > parametrization) of transformation matrices
> instead of
> > the complicated and inefficient way of using
> > compositions of animations for primitive
> > transformations. Also it is much more difficult
> than
> > it seems, to find the _animated_ composition of
> > primitive transformation which is equal to a
> specified
> > path (including parametrization) of transformation
> > matrices.
> > 
> > Does anybody have an answer to or comments about
> any
> > of this?
> > 
> > Thanks,
> > Ben
> > 
> > __________________________________________________
> > Do you Yahoo!?
> > Yahoo! Mail Plus - Powerful. Affordable. Sign up
> now.
> >

Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.

Received on Wednesday, 22 January 2003 15:59:30 UTC