Re: Declarative animation limitations

AndrewWatt2001@aol.com wrote:
>You're welcome Ken. I took time to look at it primarily because I found 
>your comments genuinely interesting. Although I wasn't immediately sure 
>why you seemed so frustrated. :)

Thanks. As for the frustration, imagine you wanted to start a new car and discovered the ignition switch was in the back seat.

>I haven't had time yet to read through the SVG 1.2 Working Draft but, as I 
>recall, the SVG 1.1/1.2/2.0 Requirements document indicated that additional 
>declarative animation would, at a minimum, be explored. So if you want to 
>see more features added then pitch in with specific positive ideas.

The documents on the web, via <http://www.w3.org/TR/SVG2Reqs/> and so on, are brief and sketchy. Nothing I see there indicates an awareness of, or attention to, the issue I am raising.

>Again if you haven't already done so take a look at the SMIL Animation 
>Recommendation and think about how, practically, we can make progress from 
>there.

The SMIL 2.0 REC is, most likely, the source of the problem. As I read it, the design of spline animation is entirely focused on timing, with no sense of the need for interpolants other than linear -- except for animateMotion.

>I am not making those suggestions to be patronising. I simply don't know 
>who you are and/or what aspects of SVG you may or may not already be 
>familiar with.

No problem. Unless you've been a Siggraph regular you might not be familiar with my contributions to topics like Bezier curves on spheres:
  "Animating Rotation with Quaternion Curves", Siggraph '85,
to user interfaces:
  "ARCBALL: a user interface for specifying three-dimensional orientation
  using a mouse", Graphics Interface '92,
or to graphics mathematics generally:
  "Math for Siggraph", Siggraph Course #23, 1989.
My professional background includes work on computer music (at CCRMA), on flight simulators (at Link), on flying logos (at PDI), on TV effects (at Ampex), on mathematics layout (at Xerox PARC), and so on.

>Well, it's up to the SVG WG to answer that one <grin/> but speaking 
>personally I would be keen to learn more about the background you are 
>bringing to this and about specifically what you would like to propose.
>[snip]
>For those of us with different backgrounds things that are obvious to you 
>may be totally impenetrable to us! :)

Alright, I promise not to use "obvious" in the mathematicians' sense. ;)

First, may I take it as implicit in the discussion so far that I *have not* overlooked something in the current REC? That to do non-linear interpolation of arbitrary values I must use my workaround? Because documents of that sort are notorious for obscuring possibilities.

Second, if indeed the facility does not exist, I believe SVG (perhaps 2.0) and SMIL should incorporate it. Specifically, the (poorly named) spline timing facility needs to have a twin that applies to values as well. Even better would be real splines for both, with control points and knots giving automatic continuity. It is absolutely essential for animation splines to use non-uniform knot vectors so that control values can be inserted and deleted with only local effects. An example of what is possible can be found in my DialASpline routine in Graphics Gems V.
  "Linear Form Curves", Graphics Gems V, Academic Press 1995, Paeth, 210-223
  <http://www1.acm.org/pubs/tog/GraphicsGems/gemsv/ch4-9/>

Third, arc/elliptical animation should be added. As a general principle, if you can draw a path you should be able to use it for animation as well. SVG should not be encumbered with SMIL limitations, nor need SMIL adopt all the paths appropriate for SVG.

Fourth, SVG should provide a uniform mechanism for accessing vectors, both as a pair and as components. For example, the center of a circle should have a center="x y" form as well as the current cx="x" cy="y" form. Conversely, paths should allow x and y to be separated. (That would fit in nicely with the animation needs, but greatly amends paths.)

Fifth, the timing along paths in players needs to be more carefully stated. (Either that or Adobe's implementation is buggy. When I used animateMotion to move a circle along a curve the timing did not match that of my kludge, even though the geometric paths matched, for neither "linear" nor "paced".)

Sixth, help the Mozilla guys get a fully working SVG. Well, OK; that one's a little selfish. :)

Finally, when I view an SVG file I don't know if I'm going to see a movie or a still, but I believe (with the developers of PNG/MNG) that I should be told in advance.

Of these proposals, I'm guessing the modification to allow scalar paths is the most awkward to retrofit. The design of general spline controls will also require careful study.

Meanwhile, do you know of prior workarounds like mine? Or do you see any way my method could be simplified?

And is anyone but the two of us paying attention to this thread?

 -- Ken Shoemake


__________________________________________________________________
The NEW Netscape 7.0 browser is now available. Upgrade now! http://channels.netscape.com/ns/browsers/download.jsp 

Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/

Received on Monday, 18 November 2002 02:48:40 UTC