Godot Motion Matching Design from collective view

[GeorgeS2019]

Daniel Holden motion matching is being implemented in Unity3D and I think it may be prudent for us to with another perspective from another Game Engine e.g. Unity3D and then re-examine how best to do that in Godot.

The Original 2019 Godot Motion Matching UI was designed and implemented by Juan Linietsky @reduz

The key question is scalability of @Remi123 Godot4 Motion Matching solution by being flexible in incorporating new Motion by e.g. importing new BVH files.

Pre-processing to store

Pose => Motion Data

Features => Motion Features

[Remi123]

This project has scalability as one of its core foundation. Since many users will try to use it with very different quality of animation, from professional post-processed motion-captured animations to Mixamo animations to their own animations of varying quality, the system must be robust, easy to debug and easy to fix.

Nomenclature:

• Features : Extract information, most of them time in the model local space relative to the root bone. Example include current velocity, bone positions and velocities, and trajectory point at x point in the future. Each features has a dimension size required for serializing the data. The sum of all the features dimensions is named K, because we will use a KDTree
• Serialization : In MM term, we populate all the features information into an 1D array of size K.
• Baking : The act of looking at each animations and extracting the features information at time T and adding those information to the KDTree.

Some comments about my project and some possibilities it allows.

1. Animation Re-targeting make importing BVH, FBX and GLTF animation a non-issues for this project. My own project use a mix of motion captured and mixamo animations without trouble.
2. Debugging is important. Each features is able to show a gizmo ( only in the editor for the moment) showing lines or meshes to show velocity, bone position, etc.
3. The Kdtree implementation that we choose has three distinct advantages over using other methods : Weight, void* Data and a Predicate,
   1. Weight allows to specify the importance of different features over others. The trajectory is usually the most important in locomotion.
   2. Void* allows me to reference some data at each node. I use it to store a bitfield representing the category ( Walk, run, etc)
   3. Predicate allows to filter results. I use it for the categories, but I also have ideas in the editor.

What this project aims is to provide multiple type of features, ones more adapted for typical locomotion that are continuously updated, others would be better for Melee Combat similar to For Honor, or other better used for Parkour. Each would be hosted by it's own kdtree and the user can select which one are active by code. This is what we define as scalability in this project.

This project is still a WIP and as such some features were implemented as a prototype for now.