In other words, getting a single animation to play will take a day. Getting an entire animation system ready for use in a modern 3d game can possibly take much much longer (exporters, animation editors, timelines, skeleton editors, state machine editors, etc... etc...)
And learned motion matching is when you simply approximate a motion matching controller using a neural network to save memory and computation time (if you've read the paper). But it requires you to already have a well-made motion matching controller beforehand, so I don't know if it's a technology that can be applied to the majority of gamedevs.
ML in animation doesn't actually do anything useful according to friends in production at Ubisoft. As the paper says itself
> Naturally, searching a larger database means poorer runtime performance too. This is why we say Motion Matching scales poorly in terms of data.
It's a neat experiment but ATM AFAIK has not been used in a production title because of its limits.
Speaking from experience: I've written dozens of 3D animation systems for games and film VFX. I've been writing 3D animation systems since the 80's.
This is the classic AoS vs SoA ? SoA can be composed arbitrarily and feels more natural to design. But SoA is usually optimal for the hardware.