Chapter 6. Animation

Table of Contents

6.1. How does it work
6.2. Comparison with VRML interpolator nodes
6.3. Future plans
6.3.1. Perform interpolation at rendering time
6.3.2. Handling of VRML interpolator nodes

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:

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.

6.1. How does it work

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).