Roadmap for Better Animation Tools

Hi,

What is the roadmap for improving the old Mecanim-style animation state tools for the future? Much of the team wants to move to UE4 for the more mature and flexible animation toolset. I understand that the underlying Playables system is getting work, but even if we have a technical background, writing Animation jobs for every animation controller is not a great way to go. What is the timeline for seeing that work populate back up into the editor tooling? Are the Mecanim tools being improved, or are you working on a whole-sale replacement?

I've seen some of the latest rigging system packages, but they seem mostly focused on simple procedural composition in a list of operators. It's useful for simple tasks and additive systems, but organizing a 50 state hierarchy with multiple types of blending would be a nightmare without a visual tool.

Here are some of the main things we find difficult.

- There's no good way to manage duplicated behavior between state machines.
If we have 50 characters that do similar, but slightly different behaviors, we have to have them all use a single "uber-graph" or duplicate all of the functionality between 50 different graphs. Neither of these are great options. We use the uber-graph setup to avoid duplicated work, but this comes also at a performance cost and limits the types of things we can do because of how difficult it is to manage.

UE4 accomplishes this because their animation controllers are Blueprints that can have simple scripts, composable functions, and can inherit from one another. This aligns much better with what animation controllers are: procedural scripts. State machines are only one piece.

- Animation Override controllers are rarely useful beyond the most basic swapped animations.
It's really not common for different characters to only differ by their animation clips. It's much more common for them to have an extra state or two, or extra blend trees.

- Blend Trees can only be leaf nodes.
As far as I'm aware, Blend Trees can only be leaf nodes in the state machine hierarchy. This is really limiting for a number of reasons.

Notably, we don't do a ton of work with traditional humanoid systems, and if we do, they're usually unique rigs that don't fit the standard humanoid IK mold.

Thanks!

 

Appreciate the response, thanks!

 

About this new animation system, will it still work with the Playables API? I've been studying it and AnimationJobs and it seems to me like it's abstract enough for it to work with pretty much the same API. It's important to me because I'm trying to write my own animation toolset, and depending on how well this goes I might want to support it on the long term, and for that it would make sense to change the backend to work with this future DOTS way.

 

The new DOTs animation won't support playables, but the API is pretty close to playables, it basically a graph, and we are already porting our animation rigging package which use animation jobs to DOTs animation.

We won't support animation jobs as is but it really close, we have the concept of animation stream like animation jobs, we also have a bunch a node graph like a mixer, layer mixer, clip, retargeter, so it should be pretty easy for you to convert your animation jobs to the new system and build a graph that look like the playables graph

 

Oh, that's great! Thank you!

 

The package for the new animation system is actually available via the package manager on staging. It almost looks usable, except it doesn't include the required shaders that do the skinning . But further along then I would have thought at this point. They must want to have this fairly polished for their first public preview if it's going to be next year.

 

If the new animation system won't support the Playable system, what will the playable system largely be used for? Is it being deprecated, and will something replace it? My understanding was that it was being built to be a layer underneath the various animation systems in the engine.

 

I've been working on something in regard to this thread's issue these couple months, as I have come to pretty much the same realizations. What I'm trying to do is just straight up imitate UE4's animation system to whatever degree I'm able to.

The point is not ~really~ trying to make it work and be good and useful as it is proving to myself I can actually do something about it. The amount of work involved in actually reaching feature parity with the Animator is already pretty jarring to imagine, much less UE4's animation system. So I can't say anything close to it will actually ever happen. And as @Mecanim-Dev said, Unity is alread working on the next thing for DOTS, so it's not like it would be of any use, anyway.

What I have implemented to this point is VERY basic. I have a single parameter, which I've used just to test stuff. Next step is making it an actual list. I have an animation sample node and a 1D mixer node. And that's it. I can plug animation nodes as much as I want, and it works. It would also probably be pretty easy to recreate most other blendtree types, with the exception of their Inspector UI. That I haven't even though much about yet. Might actually be more work than I think.

What I'm aiming to do soon is implementing AnimationJob nodes, which was something I studied the possibility since the beginning as they could allow for arbitrary animation post-processing via code, such as IK nodes. With that implemented I think I'll try a state machine. Which might not happen at all. Don't know. Fingers crossed.

Of course, before any of that I need to do a lot of refactoring.

 

Would this include the ability to define the type of animation curve used across and between (certain) keyframes in a clip?

 

Could you give us more detail? I'm not sure I understand exactly what you mean by define the type of curve between keyframes

are you talking about different interpolation mode?

 

If you've seen the Animation Bootcamp: Procedural Animation video, as soon as the physics discussion is over, it begins talking about how it makes the ears and arms bounce per-bone at slightly different weights (using something similar to Constraints applied to a chain of bones). This is done by applying a spring-dampening "AnimationCurve-styled" curve on the bone chain, which affects interpolation between poses on those specific limbs/parts (without regard to rest of the clip except for the overall target pose.)

On the other hand, the run animation in that video uses "bicubic interpolation" across all 4 animation frames as a whole to smooth out a tiny 4 frame run into a really nice-looking run animation (using only a few keyframes). Later on, these keys are blended topdown with other 4 alternate poses and animations for various weapons, each bone with their own settings for the interpolation modes. Again, this interpolation is sometimes set per-bone-chain (for example, keeping the ears floppy and the arms a little loose while still following the target frame's final key pose).


There is huge benefits to indie developers who want high animation fidelity while only using a couple of poses/frames.

For example, a walk, crouch-walk and a run clip (all with the same placement of 4 frames) can be easily blended between one another, while certain limbs / bone chains can be affected by different kinds of interpolation influences (like physics input or a pose overlaid on the upper-half of the body for weapons -- or even for the body as a whole, since these frames are really easy to author!)

Interpolation is key to being able to do these kinds of animations, so having creative control over when, where, and how this interpolation applies (and to what bones, chains, or keyframes) in a keyframed clip is vital.
That's why I suggest being able to control that interpolation method on a per-bone, per-chain, per-key, and per-animation level, defining the interpolation in the same way we set up Animation Curves, picking from some template curves (or quickly and easily defining our own, either via simple script API or via visual curve editor) to control our transitions across each of these levels of interpolation to achieve our final pose (procedurally), essentially letting logic animate for us.


Please let me know if I've explained well enough.