Animation and State Engine
Table of Contents
Introduction
Ventuz contains a feature-rich, non-linear animation system with several ways to create, change and control animations. It is based on the same classic Keyframe Techniques used in other animation packages. The realtime capabilities of Ventuz, however, offer a lot more possibilities than traditional animation tools. Almost every parameter can be animated. Ventuz supports a virtually unlimited number of independent animations, each with its own timeline and keyframes. While breaking the strict relation between scene and timeline, so common in most 3D applications, can be confusing to new users, it harnesses the power of interactive animation unlike any other software.
Ventuz offers two different types of animations. Procedural Animations are automatically generated animations based on mathematical functions. They can be used for simple movements or to loop background animations. Regular Keyframe Animations on the other hand offer complete control over values and timing of an animation.
The main difference between Ventuz and a traditional 3D animation packages is that the order and timing of animations do not have to be predefined. Where movie makers design storyboards and develop precise scripts to derive the perfect sequence of events, there simply is no one perfect sequence when dealing with realtime since one never knows what will come up. Perhaps a speaker decides to take another route at the last minute or a football player has an injury in the middle of the game. Ventuz gives the operator the power to play with such elements and react to what is happening.
Procedural Animations
The simplest way to animate something inside Ventuz is to use the Mover node, one of the most flexible and frequently used nodes. Based on the specified mathematical function, it generates output values that can directly be bound to the Input Property that are to be animated (e.g. the rotation value of an Axis Node). The Mover - via the various Mode options - can be used both for elements of the scene that are continuously animated or that elements that only perform their animation if a certain event occurs. It is safe to say that for the majority of situations, the user will not even have to use the Animation Editor thanks to this single Node.
Keyframe Animations
For more complex animations, the traditional keyframe animation process can be used by binding an Input Property to a Keyframe Animation node to create a new animation. Dragging a property to the Animation Editor adds this property to the existing animation. Alternately, pressing CTRL and clicking 
on the property (name) achieves the same effect.
There is no one single animation timeline for a scene as in other 3D applications! Each Keyframe Animation node has its own independent timeline and there can be any number of Keyframe Animation nodes in a scene. All work in the Animation Editor changes information inside a Keyframe Animation node, not the scene.
Since the creation of a keyframe animation is beyond the scope of this document, please see the documentation of the Animation Editor for further information. In summary, a keyframe animation contains information about the target values of the property at specific points in time called keyframes and the animation will interpolate between those values. This way very complex animations like camera fly-through can be achieved.
A scene can have any number of animations, each animating any arbitrary combination of input properties, even from different Nodes. Most importantly, each animation has its own timeline and transport Control.
State Engine
While an animation can be used in a scene all by itself, there are often higher-level dependencies when building complex scenes. For example, if a number of animations should all start when a certain event happens in the scene, or, even more complex, the animation to be done depends on what previously happened in the presentation.
The solution to those problems comes in the form of the Ventuz State Engine. It allows the user to define a customized State Machine that expresses pre-defined situations and transitions between them. The basic idea is to re-formulate the problem of "do the right animation" to "go from the current situation to the one we want to be in", automatically choosing the correct animation.
A State is an abstract entity that represents such a situation. By itself, a state is completely unrelated to the scene and there are no hard rules what a state can or cannot represent. It is up to the user to define what situations can arise in a scene and which of those should be represented by a state. For example, the beginning of a scene could be a state, or the fact that a sub-menu has opened that needs to be closed before proceeding.
What gives states meaning and establishes the connection to the scene are the transitions between them. Sticking with the example above, from the "sub-menu open" state, there might be a transition to the "sub-menu closed" state which has a transition to the "main menu closed" state. There might or might not be a transition that goes directly from "sub-menu open" to "main menu closed", depending on how the author designed the scene. Each transition is associated with a Slice, an animation timeline that is independent of any other animations. When the State Engine changes from one state to another, it triggers the animation of the respective transition. It is the responsibility of the author to create a keyframe animation that will change property values such that the situation associated with the target state is established at the end of the animation. I.e. at the end of the "sub-menu open" to "sub-menu closed" animation, properties should have changed such that the menu appears closed to the audience.
Ventuz provides two kinds of states: Hard States and Soft States. Both represent a point in time on one or more slices but whereas a hard state has a respective set of keyframes for the animated properties, a Soft State does not. In the vast majority of cases, a Hard State should be used, as the author can specify a set of specific values that are current at a certain state (i.e. Axis A has the X-position property at 5.1, Y-position property at 2.0, the Material has Alpha at 0%, ...) and store it in the keyframes of the Hard State. Designing an animation slice thus boils down to deciding how the transition between the start and end keyframes should look but the two end points are already set. This also ensures consistency when multiple transitions from and to a state exist.
In contrast, a Soft State is not bound to specific keyframes. Instead, it is the users responsibility that the values interpolated at the state on each of its slides results in a consistent visual presentation. One example on where to use Soft States is an object that should rotate 360 degrees on a transition from one state to itself again. When using a Hard State, the start and end point would be fixed to a single keyframe and thus only one property value could be used for start and end, making it impossible to assign 0 for the start and 360 for the end. With a Soft State however, the state is independent of any keyframes, so one can be added at the beginning with 0 and one at the end of the animation with 360.
See also HowTo: Create a Turntable State Logic