Re: [css3-2d-transforms] matrix animation

> On 26/03/2009, at 6:45 AM, Dean Jackson wrote:
> > Olaf,
> >
> > On 26/03/2009, at 12:49 AM, Dr. Olaf Hoffmann wrote:
> >> I think, it is not a good idea, that a matrix is decomposed in an
> >> (arbitrary)
> >> set of other transformations for animation purposes, because:
> [snip your points]
> >> To resume, I suggest to skip the decomposition idea completely. This
> >> avoids mathematical problems and paternalism of authors.
> >
> > We strongly disagree. We came to this approach for a few reasons:
> [snip my reply]
> If you wanted more proof here's an example from the apple engineer who
> implemented the decomposition:
> Imagine animating from [0.707 -0.707 0.707 0.707 0 0] to [0.707 0.707
> -0.707 0.707 0 0], which is an animation from 45 degrees to -45
> degrees. Without decomposition at 50% you have [0.707 0 0 0.707 0 0],
> which is a rotation of 0 degrees (this is correct) but with a scale of
> 0.707 (definitely incorrect)? You'd see a box rotate and shrink, then
> continue rotating and grow again. This would be even worse animating
> from 0 to 180 degrees, where the box would shrink to nothing at the
> 50% mark.
> Dean

I think, the main points are, that it can cause mathematical problems
and that there are applications for the matrix animation without 
decomposition as well, currently not accessible at all. Authors should 
at least have the choice, what happens and of course the mathematical 
problems with the possibly missing inverse have to be avoided 
somehow within the decomposition approach. 
In general I do not dislike the idea of decomposition as an additional
feature to the simple interpolation between two matrices, then authors
have even more the choice, what they really want. However in case
this is not possible, authors have already the possibility to provide a
complete set of transformations, then they should have the possibility
too to interpolate between matrices. 

I think, no author will compute from a set of transformations a matrix,
write it down and expect, that the original set is reconstructed by the
viewer for the animation - and the suggested method will not manage
this anyway. If the author writes down this set, this is transparent and
understandable for him/her and this is, what will happen in most
cases anyway.
Error management for illformed combinations is another problem,
but this is not very interesting for authors, because typically they
do not want to publish errors intentionally, therefore a visible indication
for a stupid notation will be much more useful for authors as a
composition/decomposition mechanism to hide such errors - 
for example no animation at all, if initial and final set do not fit 
together. This will trigger authors to fix errors instead of assuming, 
that everything works.

That matrix animation is not possible currently in SVG without some
complicated tricks is annoying enough. And I tested the animation 
behaviour for the matrix case in SVG and it works as expected - 
at least for me. Simple possible applications are for example 
animated IFS (iterated function systems).
And I think, there will be no surprises for 3D (4x4 matrices) as well
for such application - but of course it looks quite different than such
a decompostion, that is the reason, why it is a quite different 
interesting feature.

In the example above you automatically think about rotation - why?
There is nothing incorrect or looking strange if you do not have those
other transformations or concepts in mind. If you need a rotation, you
can use rotate etc, not matrix, obviously it is inefficient to simulate a
rotation with something like a values animation with a lot of matrices.
In the same way it is inefficient to simulate a matrix animation with 
a huge number of values animations of a set of other transformation,
what is possible, but not very useful if one can specify a matrix directly.
If this is decomposed, authors need a large set of explicitly noted
interpolation values to express, what they really want, resulting in
something like 10 to 20 values per second animation.


Received on Thursday, 26 March 2009 11:07:02 UTC