[X3D-Public] my musings on O3D and JavaScript on the web

Joe D Williams joedwil at earthlink.net
Sat May 2 12:17:09 PDT 2009

> I find conventional page-flipping animation very easy to understand. 
> But I find interpolators difficult to grapple with.

Take another look Miriam, The key holds a list of times. If it has 6 
values, then you would draw 6 cels, to be displayed at those relative 
times. You define each of those six cels in the corrsesponding 
keyValue field.
So, at the first key t=0, the interpolator's contibution to the first 
cel is set. To produce realtime data for the next frame, the 
interpolator's contribution is computed according to relative values 
for the first and second keyValue. If the time is exactly the same as 
the second key, the the data for the seoond keyValue is used. If the 
elapsed time is less, then the actual output is computed by deriving a 
value proportionally in-between the two values.

So, compared to conventional page-flipping animation, each key and 
assocated keyValue gives you what you see on each page when flipping 
the pages and the interpolator algorithm gives you the in-between 
images according to the actual elapsed times.

Values for the key can be anything between 0 and 1, and any interval 
between the keys is OK. The time interval does not need to be uniform 
(linear), only increasing. You can natively build any sort of 
animation curve(s) you wish. And there are also ease-in and ease-out 
This is a big difference between fixed-frame-per-second rendering like 
flipping keyframe pages at intervals and realtime animation that 
depends upon creating an image for every frame, no matter when it 

> Ask someone how they want to move something and they'll generally 
> say something like "that direction at that speed", whereas 
> interpolators require start point, start time, end point, end time, 
> and if the movement is not constant then one or more inbetween point 
> and inbetween time too.

I think for realtime, you need to consider all that any way you get it 
done. The inbetweens are always happening except for t=0 and t=1 
because in practice the exact key/keyValue combo will almost never be 
asked for.

Also look at the Rigid Body Physics component. That is where you get 
to apply a force that results in movement according to definable 
rules. That way you can ask if I push it this hard for this long, how 
far will it go.

I'm at the point where the hard part about getting interpolators to 
work right is that sometimes what you want is a blend or several 
interpolator outputs of the same type to animate an object, or enable 
a nice transition from one animation to another, or collecting various 
animations in a sequence. At this time there are a couple of 
suggestions for authoring best practices that are being evaluated by 
the X3D h-anim working group.

There are several different interpolator nodes. The basic one is:

X3DInterpolatorNode : X3DChildNode {
  SFFloat      [in]     set_fraction  (typically from 0 to 1)
  MFFloat     [in,out] key  []   (typically from 0 to 1)
  MF<type>  [in,out] keyValue [] (keyframe values)
  SFNode     [in,out] metadata  NULL [X3DMetadataObject]
  [S|M]F<type> [out] value_changed

When ready for the next frame, set-fraction tells the current relative 
time which is compared with key entries.
If the time exactly matches a key, the associated keyValue data is 
produced directly.
If the time is in between two key entries, then the actual data value 
is computed by interpolation (linear or Catmull-Rom spline depending 
upon the interpolator) between the associated keyValue items.

Thanks and Best Regards,


More information about the X3D-Public mailing list