The animation standard

Every motion you see on an AI character powered by KuteEngine is a combination of:

• Offline animation, which can mean animation that was

  • hand-crafted in a 3D program such as Blender or Maya;

  • or created via motion capture (mocap);

  • or generated offline via machine learning (ML).

• Online (or procedural) animation, which refers to the use of code and physics simulation at runtime to transform the bones and change the blendshapes on a character in a coordinated manner. Procedural animation is always synthesized on the target device, no Internet connection is necessary.

This mixed approach is referred to as semi-procedural animation, and we have found that it can combine the best of both worlds.

--> Offline animation defines the overall 'feel' of the movement, and ensures that it remains under the fine-grained control of the art director.

--> Procedural animation adapts offline animation to the specific situation, thereby allowing it to interact with the world. This adaptation leads to vastly reduced content needs.

KuteEngine's animation system cuts the need for offline animation by a factor of roughly 5-10 compared to traditional game production pipelines.

Controlling the offline animation system

The offline animation system has two major parts, the root state system and the facial state system. They both revolve around a number of primitives and conventions. Together we refer to them as the animation standard of KuteEngine.

Any offline animations you wish to add to your characters need to conform to the animation standard. Fear not, this ends up being easier than you might think. The TL;DR is that:

1. all your animations have to begin and end with a well-defined defined pose called a root state or a facial state (which can be defined by yourself), and

2. you need to tag your animations with a small handful of animated properties so that offline and procedural animation can collaborate in the correct way.

The root state system (RSS)

The root state system comprises the base layer in the animation architecture and thus animates the entire character, including it's root via root motion. It's main primitive is - you guessed it - the root state (RS). Here is an example of RSs Stand and Walk from our humanoid package.

RSs are always looped animation states. They can be static poses (which is often the case for non-locomotion states like Stand or Sit) or 'real' animations (for states such as Walk or Run). The latter are usually composed from nested blend trees.

Examples of the three main primitives of the RSS from our Humanoid package

The RSS defines four additional primitives to allow switching between RSs, adding useful or expressive actions and creating variations.

• STs (self-transitions). Displayed on the right of the figure above, STs always start and end with the base pose (at the first frame) of their corresponding RS. Here are examples of ST_Stand_Turn_Left and ST_Stand_Stomp_Left.

• STCs (continuous STs). These function like STs, except that they are not required to start and end with 'their' RS. Instead, they can be cross-faded into and out of via prior/subsequent STs. This allows better chaining of long ST sequences and can be used to create complex behaviors such as a bird cleaning its wings in RS Perch or a cat kneading with its front paws in RS Lie.

• OTs (other-transitions). These define transitions between RSs. As with STs, they must start with the base pose of the starting RS and end on that of the target RS. Here are examples of Stand_to_Jog_Default and Stand_to_Walk_Default (the latter captures a state in the blendtree called 180_Backward_Left).

• BAs (body attitudes). Finally, BAs are additive modifiers of RSs and their associated STs and OTs. They interact with STs/OTs in interesting ways. For one, both can be used to 'transport' BAs, meaning that the BA can change over the course of the transition using a configurable curve. STs/OTs can also suppress BAs to avoid ugly self-penetrations. Here you can see BA_ScaredLeft and BA_LegsSpread, both of which modify RS Stand.

The magic of the RSS happens at runtime, when KuteEngine combines, chains and modifies RSs, STs, OTs and BAs to create realistic and varied yet controllable animation streams.

The facial state system (FSS)

The facial state system mimics the architecture of the RSS and applies it to the face. (Depending on the character type, 'face' may include the ears, a crest or other parts of the head.) This allows high-quality expressive facial animations, such as those seen in animated movies, all while being interactive and controllable.

Examples of the three main primitives of the FSS

The analogs to RSs, STs and OTS are, unsurprisingly, called facial states (FSs), facial STs (FSTs) and facial OTs (FOTs). All facial animations are assumed to allow direct cross-fading, which means that there is no need for an analog to STCs in the FSS.

Controlling procedural animation

KuteEngine uses dedicated IK solvers to procedurally animate the limbs, the inner parts of the body, the head and the eyes. Controlling them is very easy as it's mostly automatic.

• To control head and eyes, use one of the Look* service activities (SAs), such as LookSimple, LookDouble, LookAround and others. They all expose parameters to give you fine-grained control over the result.

• Inner-body and limb effectors are handled for the most part automatically, e.g. as part of SAs that grab things. The exception are root-controlling SAs (such as Stay), which allow you to access a BodyConfig structure where you can add manual IK effector offsets and specify how they will be applied. Note that BodyConfig normally doesn't get applied directly, but over the course of an OT or ST. This happens together with the body attitude (or BA, see above), which can also be set via BodyConfig.

• Finally, grounding of feet or paws is fully automatic. It can be switched off to handle situations where the animation system would falsely assume that the limbs should be grounded.

Using our free rigs to create animations

See Adding more animations.