RE: function-based input for <animate> (ACTION-3142)

Hi Erik and all,

Thanks for the opportunity to explain this in a bit more detail. Many of my comments were rather cryptic, I realize.

In short, the proposal is to extend animateMotion so that it may effect other pairs of attributes of objects than just their x and y positions.

What I was getting at here is the fact that declarative animation has limited ability to control the way in which attributes change values.

Either, in the case of <animateMotion>, there is the ability to control the x and y positions of SVG elements through a path: a function mapping time to x and to y --from that it is natural to affiliate the x and y positions of points to follow that path.

In fact, unless one uses <animateMotion> and instead animates the x and y positions (as, for example, using cx and cy of ellipses or x and y of rectangles) then motion tends to be linear:

a. http://srufaculty.sru.edu/david.dailey/svg/newstuff/SMIL3.svg 
b. http://srufaculty.sru.edu/david.dailey/svg/newstuff/SMIL4.svg 
c. http://srufaculty.sru.edu/david.dailey/svg/svgopen2008/bouncing1.svg 

In http://srufaculty.sru.edu/david.dailey/svg/SVGOpen2008/keySplines1.svg or in http://cs.sru.edu/~ddailey/svg/pathRep7.svg, the use of keySplines to produce nonlinear changes in the position of a circle is illustrated. Two things are noteworthy: a) use of keySplines is nonintuitive (students have a hard time with it) b) in order to effect the nonlinear effect, the time signature is also warped, meaning that the animation speeds up as the changes depart from linearity.

Replicate suggest a number of extensions to this paradigm for animate, so let me explain:

Consider how the same set of values of x and y is used for either <animate> or <replicate> in the following:

http://cs.sru.edu/~ddailey/svg/repPath1c.svg

Namely:

<replicateAttribute attributeName="y" values="200;50;200;50;200;50;200;50" />
<replicateAttribute attributeName="x" values="40;600;40;600" />

And

<animate attributeName="y" values="200;50;200;50;200;50;200;50"
dur="8s" repeatCount="indefinite" />
<animate attributeName="x" values="40;600;40;600"
dur="8s" repeatCount="indefinite" />

The replicate and the animate follow precisely the same path.

As explained in examples 7.1, 7.2 and 7.3 [1], however, at 
http://svgopen.org/2010/papers/46-A_proposal_for_adding_declarative_drawing_to_SVG/index.html 
replicate has the ability to take not just its x and y values from a bivariate path, but in fact, any of its quantitative attributes from such a path.

Compare
http://cs.sru.edu/~ddailey/svg/repPath1a.svg 
and
http://cs.sru.edu/~ddailey/svg/repPath1b.svg 

In the former, it is like animate -- both x and y vary linearly (though with different cycles). In the latter, the values of x and y are taken, as with animateMotion directly from a curve, using replicatePath (the <animateMotion> <mpath> </animateMotion>  notation is argued to be unnecessarily cumbersome!)

Now observe how in 

http://cs.sru.edu/~ddailey/svg/pathRep1.svg and
http://cs.sru.edu/~ddailey/svg/pathRep2.svg 

The shapes take not just x and y coordinates from the underlying path but height data as well. This is what is proposed for <animate>: namely that values of all quantitative variables (including color channels) be yoked to x, y values of a path.

Consider the example at

http://cs.sru.edu/~ddailey/svg/repPath1d.svg 

In it three replicates and two animates are drawn. The second animate follows the replicate exactly -- both take their x and y data exactly from the curve. But in the first example, the x and y data for the animate is taken from the curve, but so is the height data. This is "faked" by adding another animate -- a linear one that only approximates the nonlinear motion demanded by the drawn object.

So the proposal is this: that there be an <animatePath> command that affiliates changes in an animated object's attributes in accordance with data specified by a path:

<animatePath xlink:href="#curve1" xattribute="cx" yattribute="cy"/>
<animatePath xlink:href="#curve2" xattribute="rx" yattribute="ry"/>

Would serve to animate an object's position so that it follows a curve, but it would also have its size vary according to yet another curve.

The ability to precisely craft a shape or an animation should be evident from a bit of play with
http://cs.sru.edu/~ddailey/svg/pathRep2JS.svg (ellipses) or http://cs.sru.edu/~ddailey/svg/pathRep5c.svg (rects).

Use cases:

While many of the things one might animate can be directly yoked to an x-y curve, such as x, y, cx, and cy of rectangles, circles and ellipses, many things, both geometric and otherwise cannot: rx, ry, height, width, transform=scale(scalex,scaley) transform=translate(x,y) are the most obvious. But there are many more.

Whenever precise control over the rate of change of an animation is needed, then this is a use case. 

If, for example, a figure is receding into the distance, but following a nonlinear path, then its apparent size will not vary linearly, nor even as the combination of two or three lines (as many authors have had to attempt to approximate).

When one is animating texture such as in 
http://cs.sru.edu/~ddailey/svg/feDisplacement2.svg

http://srufaculty.sru.edu/david.dailey/svg/spout2.svg 
or
http://srufaculty.sru.edu/david.dailey/svg/texture/water.svg 

The desire to make textures move to simulate water, clouds, smoke, fire, often involves the animation of the baseFrequency of feTurbulence.

In order to simulate naturalistic transitions, a curvilinear effect (without distorting the time signature using keySplines) would be far preferable

Note in http://cs.sru.edu/~ddailey/svg/feTurbulence13.svg how the linear oscillation of baseFrequency leads to undesirable bouncing as its value transitions though its cycle.

The ability to control this oscillation directly through a user-defined curve would be far preferable.

In general, I think most of the use cases pertain to situations in which we wish objects and the grain of objects to change size, but if we had precise control over the sizing of objects, then the ability to precisely control their colors as well might become imperative for naturalistic drawing effects.

In short, I think it would not be a major extension to the spec, not to viewer implementations since most of the interpolation apparatus will already have been put in place to implement animateMotion.


cheers
David

[1] seen at http://cs.sru.edu/~ddailey/svg/pathRep0.svg http://cs.sru.edu/~ddailey/svg/pathRep1.svg and http://cs.sru.edu/~ddailey/svg/pathRep2.svg


-----Original Message-----
From: Erik Dahlstrom [mailto:ed@opera.com] 
Sent: Friday, November 25, 2011 5:15 AM
To: Dailey, David P.
Cc: www-svg@w3.org
Subject: function-based input for <animate> (ACTION-3142)

Hi David,

could you explain in more detail what you envisioned in this requirement:

     http://www.w3.org/Graphics/SVG/WG/wiki/SVG2_Requirements_Mailing_List_Feedback#Function-based_input_for_.3Canimate.3E

What kind of use-cases were you thinking of for that?

-- 
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed

Received on Sunday, 27 November 2011 21:31:00 UTC