Animation and State Engine

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, which is very common in most 3D applications. That can be confusing to new users, since 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 traditional 3D animation packages is that the order and timing of animations do not have to be predefined. For example, filmmakers design storyboards and develop precise scripts to derive the perfect sequence of events, on the contrary, there is no single perfect sequence in realtime, since one can't anticipate live events. 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 for elements of the scene that are continuously animated or for 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.

Since the creation of a keyframe animation is beyond the scope of this document, please read 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. The author is responsible creating a keyframe animation that will change property values in order that the situation associated with the target state is established at the end of the animation, e.g. at the end of the "sub-menu open" to "sub-menu closed" animation; the properties should have changed with the result that the menu appears closed to the audience.

Hard- and Softstates

Ventuz provides two kinds of states: Hard States and Soft States. Both represent a point in time on one or more slices; 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, since the author can specify a set of 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 so ensure 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.

State Types

A state is of one of four types, represented by the color of the state in the logic view. Each state type implies certain meaning and behavior in the context of an animation, see the State editing section of the Animation editor for further information.

State and Transition Methods

The State Engine can be driven by the pre-defined methods (begin, next, prev, etc.) or user-created custom methods. Those custom methods methods can be created on the corresponding Keyframe Animation node via the Edit Custom Model button in the Property Editor.

Methods can be applied via drag&drop either to a state or a transition. Another way is to assign one via the context menu open by either on the state or the beginning or end of a transition.

Methods that are used on a state are visualized by the method icon inside the state. Methods on states are so-called Jump Methods which means whenever the method is triggered by an event, the State Engine jumps to that state without playing transitions. On the other hand, methods that are applied to the beginning or end of a transition, define what transition to choose in certain situation. In the example above, triggering the red method Method02 will cause the State Engine to animate the transition S1 - S2.

Rules

In addition every State or Transition method can be in one of the following Conditions:

Template Engine

Besides using the State Engine for animations driven by logic from within the scene, the State Engine becomes very important when it comes to template driven graphics controlled by Ventuz Director or via Ventuz Remoting.

Templates are managed by the Ventuz Template Engine which is part of Ventuz Runtime/Designer. An operator cues a template, fills in the values and takes it to bring it on screen. Based on the current state of the project, the Template Engine automatically calculates which animations have to be played to reach the target state and even switches scenes if necessary.

Templates are so powerful that Ventuz created a dedicated control application just for templated-based workflows called the Ventuz Director. In Ventuz 3 and before, users had to write their own control application where now they can build custom logics/controls based on the Director Plug-In API.

More information about Templates can be found here or in the Ventuz Director Documentation.