This is nice but ... the real "fun" of animation is handling all the variations of how to mix the data. It's easy to take a full set a bone animation data and apply it to matrices. The challenge, not sure challenge is the right word, maybe "the work" is in the all the tools and systems for using it. You can't just interpolate between frames, you need to be able to interpolate between multiple animations. You need some animations to apply to only parts of the skeleton (like allowing the character to run and shoot) which means you're some what back to sparser data ... though there are still ways to make it arrays.
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...)
But on the other hand, many games work just fine with simple linear interpolation and simple cross-blending between animations, and it's probably more important to compress and efficiently stream the animation data instead of working with a too granular set of small partial-animation snippets (for instance, not every game needs Assassin's-Creed-level dynamic climbing - but the "big engines" need to provide general solutions which enable this sort of thing).
Motion matching isn't really ML by the way, it just does simple pose searching from a motion database every frame with a heuristically designed cost function. And the problem is that it requires a good amount of raw motion capture data beforehand to exceed the quality of traditional hand-made state machines, and as a result is mostly viable for huge game companies with dedicated motion capture studios and professional actors. (For most indies, even just renting out a motion capture studio for their game is out of the picture.) In order to really get the benefits of it, you'll have to plan out something called a "dance card" for your actors (https://www.youtube.com/watch?v=_Bd2T7uP9VA), which are a sequence of actions designed to sufficiently capture enough range of the motions that the character can take. And you also need some manual labeling/tagging of those motions afterhand in order to really get good transitions. The resulting animations can be incredibly good (such as the one we see in games like For Honor and The Last of Us 2), but for most indies and small gamedev studios this isn't really economically viable, and a state machine will probably get you far enough.
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.
> If you have an animation of walking and one for drinking, Motion Matching will not be able to produce a scene where the character is walking while drinking. Motion Matching will only play back the data you provide it.
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.
You can use 4x3 bone matrices instead of 4x4, saves 25% of GPU bandwidth, also vertex shader will be slightly faster. They don't need projection component anyway.
Saw that approach in GTA 5. Once upon a time, a client wanted to collect non-trivial amount of data from the running game. That’s how I’m familiar with the way they render stuff.
unfortunately, IIUC, GA doesn't handle scaling. It's ironic the picture of a T-POSE in that article is a cartoon like character. Cartoon animation is full of "squash and stretch" which means lots of animation of scale.
Squash and stretch is not implemented with scaling. In fact, for any rational animation system (meaning one that a non-engineer digital artist can actually use) the use of scaling is simply not available in the system. Scaling in a hierarchical animation system is a guaranteed method to fuck up an untold large number of additional systems such as the physics/dynamics associated with the scaled character as well as any geometry attached to the character, as well as any sub-systems which use the now-scaled character for decision triggers. There are simply too many inter-dependent systems that rely on aspects of the environment, such as the scale of objects, to remain consistent for the entire illusion of a consistent world to be maintained.
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.
You may have scaling in your tools, but under the hood the transformation pipeline treats the result as a translation. Scales cause physics and dynamics issues, which are linked to too many related systems. That's why tools that scale have a "bake" operation afterwards, that baking is transforming scales into translations so runtime and scene logic can use a uniform coordinate space.
I’m still only circling geometric algebra – could you give me some leads on GA not handling scaling? I’ve understood it such that it did, but I’d love to dig into it however it is :) Thanks!
Although it says that it's solving the problem using geometric algebra, I really can't see how GA makes the problem easier (in terms of both conceptual simplicity or implementation). You can replace the term 'motor' in the article with 'dual quaternions' and the whole thing doesn't get any more simple or complex.
> With this in mind, I wrote a small function to traverse the hierarchical tree and convert it to this simple array. Then we yeet the hierarchical data out of existence.
This is the classic AoS vs SoA [1]? SoA can be composed arbitrarily and feels more natural to design. But SoA is usually optimal for the hardware.
Very cool! What file format did you find easiest to work with? I've been doing some work on skeletal animations and the most common format I've come across is BVH [0], but that only captures animation and bone hierarchy.
I didn't know about BVH! Right now I'm using COLLADA (.dae). I'd like to decide on a single file format and write my own parser for it, but I feel like there must be a slightly less complex format than COLLADA that still does everything I need. I'll probably spend some time comparing it to e.g. FBX.
https://docs.unrealengine.com/en-US/AnimatingObjects/Skeleta...
https://docs.unity3d.com/Manual/AnimationSection.html
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...)