Re: Sun-Java and SMIL Animation

Hi,

 > Could you raise this issue in a separate message, possible proposing
 > alternate text that could be incorporated into the SMIL 2.1 errata?

I don't think I'll go so far as to propose alternate text;
I don't have enough history with that spec or confidence that
my use of it maps well to others' to say what text should be there
instead.

But I'd be glad to point out the areas of confusion in my
reading of it and anyone else is free to amend the spec as
they see fit...

First, I should point out that my usage of the SMIL spec probably
differs from other readers' usage of it.  When I read the
spec previously just to understand how different things worked,
I was not too concerned with the details and the light
description of keySplines was fine for that purpose.  I understood
that splines were used to describe the interpolation between
values in any particular time segment.  But this time, I read
the spec as an implementor, and needed to know exactly _how_
that interpolation occurred so that I could implement my
library accordingly.

My points of confusion included:

- Basic spline math: This was easy to chase down, but I have to
say that Foley, van Dam was (for once) not my reference of
choice on the subject.  Their discussion of Bezier splines was
so theoretical and enmeshed in a larger discussion of parametric
cubic curves that I found it unhelpful in narrowing down the
details.  As I said in my article, I found the derivation
in Farin and Hansford much more concrete and helpful.  An
article by Gravesen in Graphics Gems V also helped, although
that was more about calculating the curve length than understanding
the overall topic.  And of course, copious amounts of
Googling solidified things even more.

- Spline interval vs. time interval:  It seems obvious after
the fact, but I found the assumption that the spline curve endpoints
mapped to the lower and higher values of the given time interval
(the previous and next keyTime values) to be undocumented
and unobvious.  The spec states that the anchor points are
defined by the keyTimes value, but that doesn't seem like
enough information to me.  The fact that the anchor points are
(x,y) coordinates and the keyTimes values are floating point scalars
is part of the confusion.  The fact that the first anchor point
should be (0,0) and the second should be (1,1) adds to that confusion.
And the fact that (0,0) maps to the lower keyTime value and (1,1)
maps to the higher was also unobvious to me.

- inputs and outputs: What I expect from an interpolation
function is to have one value as input, and to get a different
value in output.  The spline curve seemed to have a much different
interpretation that I took some time grappling with.  Looking
at the curve, we see that for any value of x there is some
associated value y.  The most obvious interpretation of the
spline graph, then, is to take our input t (which I define as
the fraction of time elapsed between the given keyTimes) and
pass it into the spline function as x to derive the value y.
This is obviously (now that I understand things...) not correct.
This will give a value on the curve, but it will not give the
interpolated time t' that I'm looking for.
Instead, the t that I have represents the fraction of the curve
that has elapsed.  The trick, then, is to derive the y value at
that point on the curve.
Once I understood this point, finding y for any fractional length
of the curve was simple enough.  It was understanding that my t'
was the y value for the curve length t that was the tricky part....

As I said, my use of the spec was probably different than most
readers, so my experiences may have been different.  And the purpose
of my article, and my code, is as much to educate people as to
perform the task, so understanding and communicating the details
is key to my goals in doing the work.  But hopefully this will help
the folks on this list understand what I found confusing in my
use of an otherwise thorough and useful specification.

Chet.


Bjoern Hoehrmann wrote:
> * Chet Haase wrote:
> 
>>I'll stick to my original assertion about the SMIL spec's vagueness
>>over the keySplines assumptions.  It makes sense to me now that I've
>>worked through it, but I didn't find the language here:
>>
>>
>>>QUOTE: "The keyTimes values that define the associated segment are 
>>>the  
>>>Bezier "anchor points", and the keySplines values are the control  
>>>points."
>>
>>very obvious in determining that the anchor points are
>>(0,0) and (1,1).  Nor did the short dereference to Foley, vanDam
>>help in figuring how to determine what we're actually trying
>>to calculate with keySplines.
> 
> 
> Could you raise this issue in a separate message, possible proposing
> alternate text that could be incorporated into the SMIL 2.1 errata?
> 
> Thanks,

Received on Friday, 31 March 2006 01:12:35 UTC