Table of Contents
TVRMLGLAnimation class is used to build
and render animations. When constructing it's instance
you provide one or more VRML models that have exactly the same
structure, but may have different values for various fields.
For each provided model you specify an associated position in time.
The resulting animation will change the first VRML model to the last one,
such that at any time point we will either use one of the predefined models
(if point in time is close to the model's associated time) or a new
model created by interpolating between two successive models in time.
For example, the first model may be a small sphere with blue color, and the second model may be a larger sphere with white color. The resulting animation depicts a growing sphere with color fading from blue to white.
Every animation may be played backwards and/or in a loop.
The models must be the same structurally, but most of the
field types may have different values. VRML field types that are allowed
to differ include SFColor,
SFFloat, SFMatrix,
SFRotation, SFVec2f and
SFVec3f. Equivalent multi-valued fields
may have different values too (but still must have the same number of items).
This gives you an endless list of possibilities what can be expressed
as an animation. Some examples:
Moving, rotating, scaling objects may be expressed by changing transformation values.
Any kind of morphing (mesh deformation) may
be expressed by changing values of IndexedFaceSet
coordinates.
Materials, colors, lights may change. Even such properties like a material transparency, or a light position or direction.
Texture coordinates may change to achieve effects like a moving water surface.
If you want to experiment with animations the sources of
our engine contain a program demo_animation
(see the file kambi_vrml_game_engine/3dmodels.gl/examples/demo_animation.pasprogram),
and various sample models for animating
(see subdirectory models/).
Also “The
Castle” uses animations for all creatures and weapons.
First of all, for now the scenes are not interpolated when
rendering. Instead, at construction time, we create
a number of new interpolated models and save them
(along with the models that were specified explicitly).
The property ScenesPerTime
says with what granularity the intermediate scenes
are constructed for a time unit.
If you specify too large
ScenesPerTime your animations will take a lot
of time to prepare and will require a lot of memory.
On the other hand too small ScenesPerTime value will
result in an unpleasant jagged animation. Ideally, ScenesPerTime
should be >= than the number of frames you will render in your time unit,
but this is usually way too large value.
Internally, the TVRMLGLAnimation wraps
each model (that was specified explicitly or created by interpolation)
in a new TVRMLFlatSceneGL instance.
This means that we have all the features
of our static OpenGL rendering available when doing animations too.
The suggested display list optimization for animations is usually
roSeparateShapeStatesNoTransform, since this allows
various animation frames to share as much display lists as they can.
Sharing display lists is very important for animations, otherwise
you can easily run out of memory (and preparing animations
will take a long time).