[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
helpers.
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
happens.
> 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,
Joe
More information about the X3D-Public
mailing list