As of Motion Symphony 2.0 release, all motion matching search optimizations have been embedded internally in the system and run automatically. There is no need for any user input.
For the interest of users, this section will briefly discuss the major optimizations implemented in Motion Symphony 2.0 to increase speed of the pose search. Altogether these optimizations can provide a 90-98% reduction in poses searched.
Data Driven Design (CPU Friendly Data)
In Motion Symphony 2.0 the search database has been designed in a way that is far more user friendly. The data is packed tightly in order in a single array of floats. This is much faster to iterate and compare poses than the previous object-oriented approach where each pose was an object in of itself.
Gameplay Tag Bins
Previously known as ‘Trait Bins’ this optimization is now automatic and built into the system. It separates poses based on their gameplay tags and only the poses with the ‘required tags’ will be searched at any given time. This effectively culls a large portion of the search database from even being searched in the first place and is a very simple yet effective optimization.
For example, if you have a ‘Walk’ tag set as the ‘Required Tags’ on your motion matching node, only poses already tagged with ‘Walk’ will be searched. The data is laid out in a way that all poses with ‘Walk’ will be arranged next to each other for fast iteration.
DoNotUse & Next Naturals Tag Culling
The most basic form of optimisation and one that the user can control is to use DoNotUse and NextNatural tags appropriatly. Any pose tagged with these will be culled completely from the search database providing a direct optimization in reduced pose search iterations.
In the case of Next Naturals, many poses can be culled without impacting the quality in any way. For DoNotUse poses, excessive redundant animation can be culled to without negative impact.
High Dimensional Layered AABBs
This optimization constructs high dimension AABBs around the pose search database without changing its order. There are two layers of AABBs, the outer layer containing 64 poses each and the inner layer containing 16 poses each.
Note: The data structure for AABBs does not ‘actually’ have poses contained within it, it’s just that the min and max of the AABBs are constructed using 64 poses and 16 poses in consecutive order.
Instead of iterating through every pose, the search algorithm checks the cost to the closest point on the Outer AABBs first and if it is not lower than the current lowest cost, the AABB fails and is skipped. If the AABB passes, then it’s inner AABBs are checked and only if they pass will the poses within be searched.
This optimization becomes more effective if the initial pose cost is relatively low, therefore, the next pose (from the current pose) is checked first to determine an initial cost as a precursor to the full pose search.