Official Animation Status Update (Q2 2022)

This is interesting to us!

We haven't been looking at the DOTS stuff you have been using simply because we're not interested in DOTS at this stage. A mode where Unity employees have to suffer through the abstraction olympics that is DOTS so we can get performant stuff without having to bother would be cool.

But, it would only be cool if the interface we work with is good. And, well, that means not repeating all the mistakes that makes the Animator such an utter pain. So, when you are setting out to build new systems, please take the time to ask the community about what needs to be kept and what needs to be thrown out, because oh boy the Animator is not good.

 

Unfortunately, reading the under consideration stuff on the roadmap, it gives me the impression that this realization is not shared by the animation devs…

 

Thanks for the heads up, that's really helpful.

 

I actually didn't expect animation being the first optimization issue to deal with, while searching i found about animation instancing : https://blog.unity.com/technology/animation-instancing-instancing-for-skinnedmeshrenderer, is there any hope to see a more friendly implementation of this ? What's the most popular asset on the asset store to deal with animation fps issue?

 

Probably baking mesh animations to textures, which is out of scope of this thread (please make a new thread if so). This one is specifically DOTS.

 

Hey, just a quick feedback ..

I find Kinematica Motion Matching as -Critical-, as it's next-gen Animation System the complies with the next-gen future of coding that's DOTS. Unity lacks such a huge feature & is stuck in a nightmare solution that's mecanim. 1+

The same applies to Ziva Facial Animation -Critical-, Unity should provide both the easy, and the complex facial animation, to harness the true power of its acquisition. Unity needs such a solution to advance in Animation & Competition, and to provide users with a variety of options for their workflow. 1+

- And I also suggest: Animation Graphs should expose how the logic structure behind the nodes are done in code, that will (including but not limited to):

• Allow artists' process for learning code easier in general
• Makes debugging simpler & more convenient

Remember: Make solutions comply with K.I.S.S. Simplicity + Robustness = Win-Win situation for Devs & Artists.​

 

it would be helpful if you'd mention which are the limitations of mecanim you see

imho
- humanoid rig would need 3 spine bones instead of 2
- the root position being projected from hip has problematic use cases
in some cases the root position is calculated wrong when transition happens (root offset being defined from start of animation, not blend start, probably is the cause of misplacement) this occurs with CrossFade, not sure if it comes up with state transitions

 

This thread should square you away. Let's not waste this thread and repeat those already discussed topics over here, and leave this thread only for DOTS related Animation stuff.

 

it won't have humanoid rig, root position or crossfade?

 

I'm finding the Under Construction section highly discouraging.

Having so much focus on external stuff, **fluff** if I may say, while we don't even have a wworking low-level core makes me think that Unity Animation is severely lacking a direction.

I absolutely support @GamesResurrected on his **K.I.S.S. Simplicity** point. After we have the strong workflow related to low-level animation stuff, set of simple and easy to use libraries, that solve the animation heavy lifting, only then we should talk about amination graphs, motion matching, etc.

I'm not even talking about the pathfinding and 3d character. Albeit I agree those components to be important, and used in almost any project, I have no idea why are they on a table for animation team.

We all know what happens when someone is trying to achieve everything, and I would really love Unity Animation team to succed and bring us a reliable, robust and scalable animation engine.

 

I've had many sad trials with the Animator in the past few years, so finding this thread is pretty uplifting. I'm going to describe some feedback on improvements I wish to see of all scales and sizes - I hope they're helpful, if even a little.

Starting with the biggest issue, that would go under 'animation importing'... ever since Unity released the Animation Rigging package, I've been pouring over every resource I could trying to figure out how to avoid its destructive workflows.
Specifically - Animation rigging demands that I include rigs on the hierarchy, and then recommends that I edit my animation to animate when those rigs should apply or not (which makes sense, animations let you fine tune things)... except... In order to make high quality animations, the ideal is to use a power tool - DCC applications such as Blender or Maya or what have you. When bringing over FBX animations, they cannot be edited in Unity. There was this one video from the Animation Rigging talks at Unite I believe, that recommended you duplicate your animation in the unity project view, and then edit the duplicate. This destroys the link between the animation's original keys - authored in the DCC , in order to animate some new ones that are unity specific. Basically - once you do this there is no going back, you have to start using unity to author any changes your animation will need. It is far from ideal, and forces animators comfortable in their applications to try and use unity - with its lack of power tools, instead. I've yet to find any possible, reasonable alternative, that gives me full preview of what I'm doing when working with the rigs. I'd love to animate the rigs entirely separately from my original animations, but still get a preview of how they'll affect the animation.

Switching to another issue - right now animation events feel sorely lacking. In Unreal Engine, an alternative system by name of Animation Notifications (or Notifies) offers a far richer experience. This mainly manifests when trying to author particles, audio, or similar aspects for your animation to play. AnimNotifies let you set a beginning & end event in an animation, showing as a singular track piece, similar to how Unity's recent Timeline does. On those tracks, you can assign rich information such as choosing what particle system should be played, what audio clip should play, and if your added effects should be attached to any relevant sockets (such as a sword trail being attached to sword start and end sockets, or stomp audio at the feet). Unity has no clean alternative to this - sure, I could force these objects permanently into my hierarchy, duplicate my fbx animation, and try to set keyframes to enable and disable the relevant audio / particle system components, but this is hard wiring and unclean - both to the reason mentioned before on destructive workflow, and on the lack of flexibility to replace what those anim notifies would do at runtime. (Such as, replacing the particle system to spawn based on character's unlocked abilities)

Another somewhat complex topic - there is no way to enforce the Animator to sample every key on the way to its goal. I'd like there to be a way to enforce that - even if just for specific animation events. Right now you can't enforce an animation to happen at the exact time you'd like - even with animation events. If I were to have an angular clock hand spinning in a circle, with animation events marked on hours 3 / 6 / 9, and asked unity to shoot an infinitely extending line (or a fireball) towards where the clock hand is pointing, there is no guarantee it will actually shoot those fireballs at 3.0 , 6.0 , or 9.0. These can be rather critical - as with high animation play speeds, such as skipping from 2 to 4 in a single frame, the fireball would shoot towards '4'. I understand that as a means of optimization the animator only evaluates the new timed position, but I wish it weren't a forced case. Attack speed in action games is my main reason to bring this up, with examples including making a clean sword trail that goes through all the path points authored in the animation regardless of frame-rate. FixedUpdate mode for the Animator does not fix this either, as the root is about only evaluating the new position, and not any keyframes in its way.

Scaling down the wishlist complexity... The Animator controllers expose a 'mirror parameter' which lets us control whether an animation should be mirrored, but, sadly, this is only exposed in the editor, and not in any of the runtime classes, as far as I can tell. Meaning you can't dynamically ask whether an animation should mirror or not, without giving named parameters to all of the ones you'd like to flip. This is made more frustrating because you can't easily reuse the same parameter for two animations if you'd like to only mirror one of them. (A shared parameter would instantly flip the one you're currently on, versus the one you would transition to)

It would also be nice to be able to set the Animation window to only loop through a subset of the animation (such as the first quarter to last quarter) , and to control the animation window's play-speed when previewing.

I believe the most important thing for animation work in unity would be to remove the destructive workflows first, as these reduce the time between what the developer wishes to see and what they see. Being able to get an animation that would play what you wish it to play made as fast as possible - with all the gameplay elements involved, would be great.

Thank you for making this thread! I hope to see a day where authoring animations for gameplay in Unity is a better experience!

 

I don't see any use of runtime mirror parameter since you can do it with two states and can transition to the one you want to (and keep track of) either by using trigger or crossfade().
most probably it would mess up the transition (or should wait one animation frame)

just in case, I checked, it's probably not possible even in Playables, since Animancer doesn't have it either
https://kybernetik.com.au/animancer/docs/help/

only evaluating the new position, and not any keyframes in its way

as far as I know, animation is curves, there are no keyframes, when playing an animation.
getting curves of the clip runtime before playing it would help, but still, there are the blend trees (and multiple clips)

 

The use is exactly to avoid doubling all your workload. There are a lot of benefits to be gained from mirrored animation in my opinion - even a simple symmetric run cycle & stop animation can have the both animation mirrored to match which leg is more forward when when the running/stopping state changes.

On a related note about playables and mirroring, this is an interesting post.

curves are still represented by their key points, that have timestamps, tangents, and so on, internally, though. Animation events are transitory as well, having a clear timestamp and not much else to go by. They're not likely to be curves, unless unity actively chooses to represent them as such?

 

There are a lot of benefits to be gained from mirrored animation in my opinion - even a simple symmetric run cycle & stop animation can have the both animation mirrored to match which leg is more forward when when the running/stopping state changes.

sure it would be easier, but still doable now.
I'm a bit concerned, whether implementing it wouldn't cause some limitations in other areas of the animation (and performance overhead because of the calculations). using states for mirrored works well. you can also use blend tree, e.g. 2D with a side parameter, and that's both sides in one state. (cached always performs better)

there's for example animator layers (every layer has some performance cost). if you could have the animation clip curves ahead, you wouldn't need other layers. you just play the curves directly, upperbody, arms or any mask (and even modify them before the animator plays them). Playables had this promise, don't know how it turned out

 

Hi @ChinnyBJ. I would like dots animation to achieve that you pay only for the animation feature that is actually being use and battle test and push the animation performance until over limit for mobile platform i.e. Android and iOS. The performance of currently available OOP land animation system is still really bad and u pay a lot of cost even for a lot of features that u are not using it. From what I know even u didn't use IK feature you still pay the cost for it. I want dots animation to fix and improve this current limitation. So, when u release the new preview version of dots animation I want to you to make sure every line of dots animation code is fully burst compatible.

 

Sorry if I missed something here but will the new Animation system be closer to the Legacy animation system or Mecanim?

 

No problem. Actually I currently working on dots project and would like to make everything dots eventually. Anyway one more feedback.

I believe unity official is working on dots timeline. I would like dots timeline can support putting dots animation into timeline by default and supporting current OOP land features that current timeline has at the same time. The dots timeline will also able to support dots netcode by default that able to strip all the OOP land components at server build and able to playback dots timeline track deterministically at both client and server without any desync issue. Even better u can writing conversion system for dots timeline to decide which component add and remove into client and server.

 

Sorry. More feedback. Is that Animation Graphs will be the improvement version of playable graph with animator? If yes then keep doing it. I believe Animation Graphs is the best way to solve scalable animation problem but if u have even better way to tackle the problem let me know. The experience I have from OOP land Animator is not really nice. I always have hard time to sync my gameplay with animator to get correct animation transition. It just always doesn't work what I expected. Really hard to use and get it right.

For AI Navigation, I really need a official dots navigation. I think the current navigation still has a lot of bugs and issues and would like to get a truly stable and working dots navigation. And also I believe with dots navigation I can get insane amount of performance boost.

One more things is dots AI related packages. Long time ago I ask about dots behavior tree and dots utility AI but until now still dun have any news yet. Can u give me an update for dots behavior tree and dots utility AI? I believe it's one of the essential feature that need to have to develop AI.

 

Could we have something simpler?

In the Animator setup, even for super-simple animations like a door opening, we need two assets - the Animation asset, and an AnimatorController that wraps that single asset. The ancient Animation setup where we just have exactly the Animation and then .Play() it is more comfortable, but ideally we wouldn't need that at all.

Consider some way of letting us just have the animations as a part of the prefab, without any extra assets, while still having it editable in the Animation window, and a way to just ask the animation to play, with no triggers or other fluff in the way.

 

Thanks @ChinnyBJ for keeping us updated.

One thing that I'd like to ask, will the new system have anything similar to StateMachineBehaviours.

My use case for them is not to have them run custom logic on start / update / end, but rather to hold metadata for the animation states.

I am of the opinion that having gameplay logic in the animator to be a bad design. So I basically use the AnimatorController only to setup the animations (I almost never use any parameters / transitions / conditions), and then I "annotate" the animation states with some metadata using the SM Behaviours.

Now in the code, I can play an animation by querying the metadata, and crossfading to the result state.

Do you think such workflow will be possible in the new system?

 

Would it be possible with new animation to do everything that possible today with Animancer asset?

 

You think developers know what animancer asset capable of?

 

If they really try to do good new animation tech they yes of course

But if they dont then they have chance to investigate Animancer

 

But they know about Animancer, and Animancer just uses playables under the hood as far as I understand. I'm not sure how it would benefit my workflow either. It is simple but so is calling a one line function into Animator.

 

My top priorities would be:

1- Start with a "low-level" animation solution that is meant to be used entirely in code, much like a DOTS equivalent of PlayablesAPI. I'd want something that's designed to be easy to work with from code, easy to modify at runtime, and easy to create procedurally (all in code). Then, once that low-level code-only animation API is ready and people are fully able to handle all of their game's animation needs with it, some visual node-based editor tools can be built on top of that low-level animation API. I'd imagine that the node-based tools would simply be used as a user interface to generate some animation graph data that can then be used by the low-level API (or maybe use some codegen to generate animation graph code?). The goal would be to make sure that even if you decided to use the node-based editor, the end result would be the same as if you just wrote it all in code using the low-level API, and will therefore have all the flexibility/power you could ever need

---

2- Allow DOTS users to fully use the animation system in a "pure DOTS" fashion (without having to pay the complexity & cognitive load cost of Hybrid workflows). I'm mostly saying this because I'm not sure if the top post implies the solution will be focused on Hybrid or not. More specifically:

• Be able to instantiate animated entities in a 100% GC-free and pooling-free manner
• Be able to control animations from bursted jobs
• Not requiring a companion gameobject
• Animated entities must be fully compatible with DOTS streaming & subscenes

---

3- Nothing should be string-based (animation events, finding a state node, etc...)

 

I'd like very strong performing workflows that enable mixing ragdoll at a fine granularity. It's a common pain point in Unity GameObject land, and something that competing engines have had natively for a while. Not just full ragdoll, but also being able to blend parts.

I don't need a huge fancy editor for it (don't think anyone does really) just that support so we can mix animation with physics.

 

This. This. 100% this!

Too often Unity shies away from developing strong low-level APIs to chase "features". And the moment I saw DOTS animation take a step in that direction, I started planning to write my own solution focused purely on such a low-level API. I'll be releasing it in the next few weeks, so please learn from what it does well and what its shortcomings are.

 

Haven't they started from exactly this low level type API? They didn't have node editor for a long time and everything was handled by code(in FPS Sample for example).

 

Not even close. For classical Unity, even with Playables and animation jobs, it is still impossible to directly modify the transforms of an optimized hierarchy for anything that is not explicitly exposed. This is awful because the optimized buffer is significantly faster at updating the internal transform hierarchy.

For the now defunct DOTS Animation package that we had, in order for a LocalToWorld entity to affect rendering, it had to be sucked into an AnimationGraph, go through the DFG buffer gauntlet, get dumped into a dynamic buffer, and then have that dynamic buffer broadcasted directly to rendering. There was also no way to "apply this animation clip at this clip time now" and have it reflect on all the entity transforms. Animation sampling could only be manipulated indirectly through the AnimationGraph.

 

I see, thanks for explaining

 

I'm gonna say that contrary to most of the opinions here, I quite liked what I saw from the preview packages, tons of ability to do some really complex behaviours with DataFlowGraph and nodes, reminded me a little of the StateMachineBehaviour workflow but on steroids. I'm most disappointed by the discontinuation of public previews and really hope they resume asap.

The way authoring node attachments in a hierarchy worked seemed a little odd, as will the entire authoring physics -> entity hierarchy workflow - I look forward to improvements on that side though its not strictly an animation only issue.

Given that animated entities still need some additional setup at runtime for graph connections maybe this is an area that could be handled in conversion?

I know that it was previously stated(or mentioned in passing) that DataFlowGraph wouldn't get its own visual editor, but a simple visualizer akin to the playables graph visualizer would be extremely useful for someone like me. It became pretty hard to reason with my own graphs. I went through the trouble of making my own graph just to understand my own code setup and refer back to for a relatively simple animation graph I can easily see a lot of use for DFG to be used outside of animation and the node connections can get overwhelming if all you have is your IDE to parse them.

Performance seemed a little unimpressive to me, its definitely possible I was gpu bound but I found there were no differences between the compute and vertex shaders in the nMixer test scenes, would love to know what the general ballpark for scale is on this front.

Lastly with the preview package disappearing behind the veil its hard to really give precise feedback on things as I have no idea what the team deems as working as intended vs what isn't.

Finally don't suppose we could any word on how DOTS timelines are shaping up? I did try out that package quite a while ago but it seemed like it was in an even more experimental state of preview than animation

 

One thing I haven't seen mentioned yet is creating animations at runtime. The last official word I've seen was in this thread in 2018 where apparently it was on the roadmap. That's 4 years ago now.

As the author of Animancer I usually have someone asking me about it every month or two and all I can tell them is that despite having been Unity's primary animation system for a decade already, Mecanim still can't do it and they'd have to use the "Legacy" system but don't worry Unity probably won't deprecate it any time soon despite the name...

 

Also, Update Physics mode.

The only way I know of to get a Playable Graph to run in the fixed timestep is to use AnimationPlayableUtilities.Play which is marked as Obsolete in Unity 2022 with the given code example not supporting Animate Physics mode. I've reported it as a bug (Case 1427366) so hopefully it gets un-deprecated, but it makes it seem like it's so far from the Unity dev's minds that they removed this rather important and still fully functional feature without even noticing. Or maybe I'm wrong and there is a function to do it somewhere so all that needs to be done is to have the documentation point there.

On a similar note, I recently had a user ask about the possibility of having animations updated in both modes at the same time to give consistency for physics and mechanics while also giving good visuals by updating at the rendering frame rate. I wasn't able to come up with a good way to do it, but maybe a new system could have something inbuilt like Rigidbody interpolation.

 

Second this. Very frustrating to implement a whole deal of animation mapping stuff before realizing it is (still) not possible to create a runtime non-legacy animation clip.

I think this is really important especially to generate procedural animations on-the-fly that can be easily reusable by Unity's animation system (or others, like Animancer).

 

Can you make animating multiple components of the same name (e.g. BoxCollider2D) possible?

 

hi there i just wanted to share some good news with you

gamedev-pro/dmotion: DMotion - A high level Animation Framework for Unity DOTS (github.com)

the link above is a working DOTS animation package (Has other 3rd party dependency) but the developers of these packages seem to be working closely together

it has many functionalities of the builtin mecanim animator too (not all but Some)

i'd recommend to take a look at it


Edit: I'm Not Affiliated With The Development Of These Packages

 

This package topic on Unity forum
https://forum.unity.com/threads/0-3-0-dmotion-a-high-level-animation-framework-for-dots.1315593/

 

Yes, pretty please, Animation Clip loading at runtime for mecanim would be very very liberating for us. It's about the last piece that we cant really have 100% dynamic because of this.