There's basically a set of things you need, some of which are obvious:
* Geometry
* Keyframes
* Animation method
* Animation data
The animation method defines how the animation will progress. It
can be linear, tangential, tangential smoothed, etc. This is important
for your smoothing calculations (the stuff that inserts states in
between the keyframes).
The keyframes can be formulated as a set of two pieces of data, time
and "value", where value gets plugged into the animation data at an
appropriate point.
The animation data is the stuff you want to change. The Geometry is
the stuff it is applied to.
Given all of the above, I would recommend a node that behaves much
like Switch {}, with a few specialized parameters. The following is
an example, made to look like VRML:
Animation {
# This is a typical enum list... DEFAULT, TANGENT, TANGENT_SMOOTHED, etc.
method TANGENT_SMOOTHED
# You know this will be in pairs
keyframe [ 10, 0, 20, 5, 30, 20, 40, 5, ]
# This is the static geometry
Geometry { Cube { } }
# This are the transforms that will be applied to the static geometry
# VALUE is the insertion point.
AnimTransform {
Transform { translation 0 VALUE 0 }
}
}
You can do quite a lot with the above. Anything more complicated
should be relegated to a complete behavior specification.
James
p.s. To take a look at the standard output this might have, look at
http://www.construct.net/projects/chimerium/
WARNING: THIS VRML IS HIGHLY WEBSPACE-SPECIFIC!!!! (we produced
these files for an installation piece that ran last month --
which is why it is using hacked animations that only work well
under WebSpace)
-- James Waldrop / Technical Director[email protected] / Construct Internet Design[email protected] /http://www.construct.net