Introduction
Whether you are an artist, technical animator or programmer it helps to understand how motion matching works on a theoretical level. It may be tempting to skip the theory but without it you will make poor decisions when setting up motion matching. Motion Matching is not like traditional state-based animation, the system is not black and white and when things don't work it is not always clear why. Without a basic knowledge of motion matching you cannot hope to debug it and improve the quality.
The remainder of this page explains important concepts of motion matching, why they are important and how they affect you.
The below video was made with my Unity Motion Matching asset in mind, however, the theory explained within is generic and applies to Motion Symphony as well.
Firstly, Forget About Animation Clips
Animation clips are a very easy concept to understand and rightly so as they have been used for decades to create and play animations. However, when considering motion matching we need to stop thinking about animation in terms of clips because that is not the way that 'motion matching' thinks about animation. Instead Motion Matching thinks about animation as just a large set of poses in which it can jump to any one of them at any time.
Sure animation clips are the initial input into your motion database but once this information is pre-processed by the system it is no longer handled in that form. So do yourself a favor and stop thinking about animation in terms of 'clips'. Motion Matching is about a continuous set of poses.
The Underlying Concept of Motion Matching
The underlying concept of motion matching is that we can jump to any pose in any animation at any time. There are no hard coded constraints, explicit transitions or rule-based states.
Exactly which pose to jump to at any given frame is based on a set of criteria which will be explained in more detail further down the page. In short the next pose to jump to should:
Have a similar pose to the current pose
Have a trajectory that is similar the desired trajectory (or other input metric)
A cost function is used to measure similarity of these two aspects and the lowest cost pose is the one to jump to.
The Motion Database
In order to perform motion matching, we need a dataset to work on. This is the 'motion database' or the 'Motion Data Asset' for Motion Symphony. This is a custom asset that you create, configure and process in the UE5 editor which contains all the pose data, animations and setting required to make motion matching function at runtime.
Once the user setup is complete, the Motion Data can be pre-processed. This process will generate list of poses at specific time intervals, containing the meta data for each pose, as well as a large matrix (float array) containing all the pose data in a continuous ordered form. This data can be searched at runtime and compared to achieve motion matching.
What's in a Pose
In order to compare poses, each pose requires a minimum set of data with which to compare. This data is processed and baked into the Motion Database so that it can be searched at runtime. Typically, there are two parts of a pose, the character pose (or quality features) and the trajectory (or input response features):
Note: As of Motion Symphony 2.0 it is possible to match almost anything you desire as long as match features exist for it (or if you can code them yourself). However, for simplicity's sake this section of the documentation talks about the more typical pose features used for basic locomotion with motion matching.
Quality Features (Character Pose):
For ‘Quality’ (or character pose), the typical base case is to match the root relative position of the feet and the hips as well as the body velocity and yaw velocity.
The matched atoms include:
Body Velocity (Green) - The local velocity of the character (relative to the characters current orientation)
Body Yaw Speed - The signed speed of the character’s rotation around the Z axis (Yaw)
Bone Position (Yellow) - The position of each matched bone relative to the root
Bone Velocity (Yellow Arrow - The velocity of each matched bone relative to the root
Input Response Features (Trajectory):
The most common feature used for input response is a trajectory with both past and future points containing data on relative position as well as facing direction. As a minimum, 3 points should be used (e.g. -0.5s, 0.5s, 1.0s) but more can be used to improve the realistic feel of weight shifting. Each trajectory point holds the following data:
Trajectory Point Position - The position of the trajectory point relative to the character
Trajectory Point Facing - The facing vector at any given trajectory point relative to the character
Note: While trajectory is the most common input response feature, other features such as distance matching can also be input response features. Even the body velocity feature can be used as an input when not using root motion.
Tracking the Current Pose
In order to match pose the motion matching system has to track the current pose. This is often done by keeping track of and interpolating the current pose based on the last chosen pose and the database. However, Motion Symphony also has an option to track the current pose via a utility node called the 'Motion Snapshot'. This makes it easy for motion matching transitions between different states.
Desired Input Response (Desired Trajectory)
The desired trajectory is the 'control' input into motion matching which ensures that the next chosen pose is going to help move the character in the direction that the player (or AI Controller) wants it to go. A desired trajectory matching the configuration of the 'motion database' must be generated each frame based on recorded character position history and predicted future motion. The future motion is usually predicted via user input.
As of Motion Symphony 2.0, trajectory is not the only input response match feature, but it is still the most common one. More details on other match features are available later in the documentation.