Official Animation Status Update (Q4 2022)

Amazing information. I really enjoyed reading this thread and discussion

 

Man, can you talk with the other departments in your mess of a company and decide on the state of entities? You say it's supported for production here (and heavily imply that it's ready and out): https://blog.unity.com/technology/2022-2-tech-stream-available

Elsewhere you call it a pre-release (but supported for production) which is a confusing mess on its own: https://forum.unity.com/threads/dots-development-status-and-next-milestones-november-2022.1366989

And in this thread you call it experimental.

It can't be both experimental and supported for production. The thread you linked is old and outdated btw.

Make up your minds.

 

As far as I can tell, there's been no public preview of what you're making, and no information other than "it'll do all the things".

I'll reiterate what I've said before - the animation stuff Unity has made behind closed doors with no public interaction has all had huge problems. Being heads down and making steady headway is really bad if you're making Animator 2.0.

Are there any plans to tell us anything, so we can tell you if there's spots where you're making mistakes? Or are you just going to boldly march of blindly off a cliff?

Is it even worth it, then?

My understanding was that Playables is a pretty thin layer over some pretty jobified code already. Are you actually giving us more value spending at least one year on making idk what, rather than making Playables play a little bit better with DOTS and calling it a day?

Then you could spend much more of your effort on the quality of life improvements for GameObject animation that will benefit other people than like the 12 or so that are using DOTS.

 

Hello @ChinnyBJ

I actually like Mecanim, I like the layer-system and blend-system.
Overall I focus a lot on workflows and getting things done + for the stuff I do, I never had a performance-bottleneck regarding the Animator.
Saying that, there is something missing in Mecanims default system which is triggering events!
So I know there is the possibility to trigger events using the animationclip itself, but this scales very bad since you can't just swap animations like that without having to configure all events one more time.

I don't know if this has been mentioned before, but my suggestion solving this issue would be to add the animationclips events-functionality to the animation you configure in the AnimatorController as well as to the transitions connecting those.
I think having such a functionality out-of-the-box could improve peoples workflows a lot .

 

I also think that no news is a good news

 

animation will come with dots in 2022.3 LTS and u said there is a year to release new animation, so what is animation solution for 2022.3 ?

 

only mecanim until first versions of DOTS anim will out in 2024

 

I think after stable Entities 1.0 release, official should try the best to release a public super alpha experimental package even it's not completely working and feature rich like only can support dots and not game object. At least release super alpha experimental package for people try out first. I afraid if waiting 1 more year and official release something that is not unity user really wanted then official just waste 1 more year of time.

Do u mean this new animation will support both dots and game object and it will have some kind of unified tooling to support both dots workflow and game object workflow?

 

I see but how about dots user? I guess it will convert the whole thing to full dots for dots user?

 

What new animation in the next version will look like?

I hope it be animation with graph node system

 

There are significant performance issues with Mecanim and Playables, particularly in cases such as professional use and VR.
We want a very fast animation system at a low level.
If additional development is planned to make it more "user-friendly", please focus on releasing it as soon as possible and prioritize optimization.
Without a basic animation system, DOTS cannot be considered a complete system.

 

Btw I guess official currently already have solid dots animation package compatible with entities 1.0? Just currently it's still very barebone like public 0.9.0-preview.6 and missing a lot of graphical tooling and game object compatibility. If yes then I think it's ok to schedule a new public release first after stable entities 1.0 is released this year for feedback or for early adopter to use it in production if it's enough for certain projects. I really would like to see a new public release at this year that I believe it's already over 2 years dun have any public release after 0.9.0-preview.6. The main reason why I keep stressing this is because there's always have something must-have but official will miss out. To minimize this issue as much as possible, I believe continuously release new version to for early adopter to give feedback is the solution to battle test this new animation system as much as possible

 

Hello @ChinnyBJ,
While the new animation system need another year (and I can wait).

Is it possible to update package like Playable Graph Visualizer for the sake of current built-in animation system? Using Playable AP to write our own animation system is a solid option and working nicely(Even I can write tools like this in a few weekends) but does require significient effort to figure it out by our own.

And it's a shame that this package is one of the half-finish package on official github repo.

I believe a better documentation and update package like playable graph visualizer can help developer built their own animation tool in Unity more easily.

 

Hello, you can try this: UnityPlayableGraphMonitorTool

 

I have posted a feature request about animation graph system. Will the future animation system you have mention would look like this?

https://forum.unity.com/threads/new-animation-system-with-graph-node.1387914/

 

It's - honestly - really disappointing to hear. My main issue lies with the fact, that by the time those systems will hit production stability, we'll have had about 3-4 years without any kind of meaningful update to basic animation systems in Unity.
Even systems like timeline, which technically would not even need the whole backend overhaul to become more mature and polished, get left behind. I really don't get how your internal team structure is supposed to work - how few people are there working on those core technologies, that it is seemingly impossible to fix glaring front-end/ux issues with things like timeline and animator, because some other team is still figuring out, how to completely overhaul most of the basic backend technology, which will then be the perquisite for an animation core backend team to build new anim-tech on top.

Why can't there be another, small team, that could very well work on a few UX/front end improvements, that might become obsolete in 2-3 years, when the new system hits (whenever that actually might be) - but that would still make life better for the people actually using your engine for those 2-3 years in between.

I'm talking about basic things like being able to copy/paste timeline-structures/directors/associated gameobjects between scenes, copying keyframes, improved events/signals and better documented/shown workflow for custom playables etc.
Heck, half of that would probably be able to transition to another, new animation backend without much work, because it's basically more of a UX/workflow topic than real animation work.

So far, we've been offered promises about whatever future technology there might be, without reliable time-frames - the only reliable thing at the moment is, that there will be another post in the future, telling us, why things had to be postponed another year for another really, really good reason - but this time, feedback has been heard for sure and all will be well, when the new system hits.

Sorry for the attitude - it's just really, really frustrating, because it has been an ongoing issue with so many things of Unitys development for the recent years...

But to end on a positive note:
@ChinnyBJ Thanks a lot for actually trying to keep us updated, as much as you can/are allowed to.
It would probably help a whole lot more, if we could actually see, how far your time might actually be already - it might even help to set a better outlook when we can really tell, that the new systems will be cool and all. But I understand, that it's not your fault/decision to make, so I appreciate that you try to be as transparent, as you can be!

 

I just found out that NVidia omniverse also have a great graph scripting tools for animation. This could be a great reference for same system in unity

 

mecanim is way more advanced than this.

also any animation system that is limited to flowchart-style of transitions, will be limited.

 

- In graph node system you can make sub UI for special node to serve your specific need
- Mecanim may be more advance in animation related things, but other ability is very lacking and need to switch to C# code to fine grain control in other aspect

 

so GDC is over without any mentioning of a DOTS Animation System, either that or i've missed something

 

Meanwhile, in most cases, I just need simple animations and quite a number of those with only a few requiring a full blown state machine, and I'm still struggling with the decision whether or not to invest time using the Animation component, which is much more light weight as well as completely straight forward and efficient to use (no unnecessary asset creation or assignment thereof with a completely viable, simple list of animations), yet has been marked legacy for quite a while (4y? 5? [EDIT: 5.2 docs state "legacy" already and it's from 2015, so it's at least about 8 years that it's marked legacy, with no valid, dependable alternative]).
It'd be great if its legacy status was reconsidered. So that you can depend on this feature simply being an essential part of Unity. Not a package, either. Simply a part of Unity, just like AudioSource. It's just as essential. Maybe it's feasible to maintain? Considering the complexity of other systems you're working on, it seems like a very small undertaking with huge impact on workflow efficiency. More complex isn't always better. Needlessly complex is certainly bad. I think it makes sense having a system that's not just able to play thousands of animations efficiently, but also one that keeps dev usage time low. And for that, Animation worked perfectly. I'm even actively thinking about writing animations by code rather than using keyframes just to sort this out, which isn't optimal either, of course.

 

You can play AnimationClip with just one method call:

AnimationPlayableUtilities.PlayClip()

. Below is a simple component that uses the foundation of Animator, but is more handy as Animation. (no new assets need to be created for playing!)

Code (CSharp):

1. public class SimpleAnimation : MonoBehaviour
2. {
3.     [SerializeField] private Animator animator;
4.     [SerializeField] private AnimationClip clip;
5.  
6.     private PlayableGraph playableGraph;
7.  
8.     private void OnEnable()
9.     {
10.         // play
11.         AnimationPlayableUtilities.PlayClip(animator, clip, out playableGraph);
12.     }
13.  
14.     private void OnDisable()
15.     {
16.         // stop
17.         if (playableGraph.IsValid()) {
18.             playableGraph.Destroy();
19.             playableGraph = default;
20.         }
21.     }
22. }

Though it will be appreciate that Unity make it default component.

 

Thanks for the suggestion of Playables! Last time I checked, it still made the impression it'll be a short term experiment, which is going to be deprecated soon (as Unity does often times), but it seems it's included now rather than a package (I migh be wrong) and it seems it's out of any experimental stages. Might be a replacement after all, if the performance is comparable with Animation (which I'm still not sure about).

 

The stable version of the Playable API has been available since Unity 2017, and its animation-related interfaces have not undergone any major changes in recent years. Therefore, Playable is not an API that will be abandoned soon, although it does not seem to have any new features. There are some bugs in the animation Playable, but it is sufficient for selecting one or two AnimationClips to play among a large number of them. Additionally, Playable has good performance.

Here's the official example code: https://github.com/Unity-Technologies/SimpleAnimation

 

Thanks for the extra context! Usually, even a few years after "stable" release, things can start getting shaky, but 5 years with no major overhaul seems like good news! Sounds all great so far! I'll keep that in mind!

 

Nah, SimpleAnimation is buggy and still is very slow. The blog post where they admit it is deleted now, but you can read about it here:

https://forum.unity.com/threads/legacy-vs-mecanim-performance.522456/#post-3429620

(or I guess you could hunt down an older non-deleted version in archive.org)

I'll add the relevant bit here as well:

So Simple Animation is a deprecated and abandoned pile of S***, that is really slow and has all the issues the animator has, it just has a simpler front end. That's it.

 

@AcidArrow SimpleAnimation is buggy and slow, but it is just a sample of how to use the animaiton Playable APIs, so it can't represent the whole Playable system.
The Animation Playable itself does have many bugs, but it is efficient and stable enough to use it to select a few animations from a large number and play and blend them simply. Just decide what technology to use based on our needs rather than how good the technology is.

 

It's not efficient. That is the point. It's still "the animator", Playables just allows you to bypass the horrible controller / state machine. There are gains to be had by ditching the controller / state machine, but for playing simple animation, it still has a ton of overhead.

And I don't know about you, but my needs most of the time are very simple animations with a handful of keyframes and every time I test playables / animator it is waaaay too slow for that if you want to be using it in any "significant" numbers (like... more than 20...).

I'm trying to use the technology that fits my needs, but Unity keeps insisting it's legacy and I shouldn't use it, while branding their newer stuff as efficient when they aren't (but people keep repeating they are, because Unity said so).

 

Maybe you can use DoTween or some tween asset, if animator/playable doesn't match your needs.

 

Yes, we made our own tweening library and are using that currently, in efforts to stay as far away as possible of any Unity related animation solution when possible.

This does not really negate the need for Unity as a software to have a way to play a few keyframes really fast.

 

Most of the time, my use case exactly.

20? Is that a joke? ... Well, I guess there goes the alternative to legacy Animation..

Well, 3rd party always leads to being very dependant.

Well, I guess I might as well just reconsider what I already considered:

If only Animation was there to stay, an officially supported and a lightweigt, integrated solution. I find it baffling they keep working on things like HDRP and DOTS, while we can't even have simple nice things like Animation.

 

@AcidArrow You just quoted my text out of context, I'm not say that Playable is always efficient.


Animator is designed for more complex character animations. If you only need to play some simple keyframe animations, it will undoubtedly be cumbersome and slow.

 

Then I do not understand what you think is efficient.

You said this. For simple cases this is simply not true. That is my whole point.

If you mean it's not super terrible for one specific use case, which is complex character animations, then say that.

 

And just if it hasn't been said already:
If you consider Animation "still there" and everyone can use it, please keep in mind:
"Legacy" does mean it could be removed any minute. I don't want to spend countless hours reworking all scenes and all GameObjects within that use Animation if it gets thrown out of the window any day.
The wording is quite important here and given that you have been naming Animation "legacy" for at least about 8 years makes things even more obscure. Either get rid of it or officially support it (the later of which I very much hope for). Either way, then one would know what and what not to use.

 

this has me bugging for long time

the .anim size has changed around 2020.
is there a reason for this?
haven't registered anything being changed in mecanim to cause this

the same .anims in U5.6 and U2022


if there is thousand animation files in a project that's a considerable size increase
and I guess that's not good for performance either

 

You can open both files in a text editor and see what's different.

 

the difference is that the old version file is unreadable signs (scrambled)
and the new version file is readable words (curve values, tangents etc)

if that is the reason I'm not sure it has any use / was worth it

 

Sounds like the difference isn't your Unity version, but version control settings. The "scambled" version is just the binary bytes, while the non-scrambled is human-readable yaml.

The setting to change that is the Asset Serialization Mode. This defaults to "force text" these days, but I think it used to default to "mixed" or "force binary" back in the days.

This has no bearing on the space the asset takes in builds, as they will always be stored with the binary format in builds. For most asset types, the text format is best as it can often automatically merge, but for animation files in particular, there's a lot of easily compressible data. You can consider setting your project to "mixed" and then reimporting all assets if space or import times in a problem on your 2022 project.

 

thanks. set to force binary. it is smaller but there's still a bit of difference

hm, okay. I did a re-import and then the file size is the same.
oh good. this won't bother me anymore.

 

Kind of feel like I've found a treasure map with these anim update threads Very promising to hear of the plans for the future, I was kind of expecting the current mechanim system was just going to continue this way forever.

In a huge oversimplification, anything that moves us to a system more like ue5/source2 would be a dream. The ability to input conditions into the anim/skeleton that can be then built up to create a final output anim would be amazing. Also, things like:

• Overlays can be applied at any part of the resulting anims construction
• Curve weights in the animator
• Per bone masking/ blending ( not just a section of the body like current humanoid masks)
• Transition curves between states
• More robust ( and sensible) additive animation system
• More complex ik / fbik rig
• Blending ragdoll & animation ( being able to set final end poses)
• Procedural modifiers - A tool to set offsets per bone or defining curves to create movement between stances & anims

 

I don't see why would you go for a complicated high level closed animation system, when all you need is access to animation (stream/curves etc) and you can easily do all this (bone masking, weights, blendings, overlays etc)

which is what AnimationHumanStream was to be, but feels like abandoned and should have been doing this for all anims, not just the anim playing, performantly and with any point (normtime) access and transition to

okay, we would need blend trees, but the foundation needs to be one that has animation curves access on the lowest level and with no restriction on when (mecanim can do that, but is like an exploit, nothing to support it)

I might be completely wrong though, since unity can do all already, can do motion matching, active ragdoll (mixing animation with physics), blend-tree structures, accessing/sampling curves, retargeting, so some fine-tuning, re-shuffling can potentially bring along an animation system that is robust and flexible at the same time

 

This has been my argument for a long while, and eventually I ended up implementing exactly this myself for ECS. Raw control over when, and how animations are sampled and applied. My solution doesn't use curves, but a different kind of compression, but still accomplishes the same goals.

Once you have something like this, anyone can build any higher-level solution on top of this. However, if a higher-level solution achieves the goals of a particular user, that user will likely not see the value of this lower-level control API. Unfortunately, Unity has fallen into this trap numerous times as of late and have focused heavily on high-level out-of-the-box workflows in much of their recent solutions, with extensibility being very much an afterthought. I would be shocked if this new animation solution being worked on has low-level feature parity and performance parity with my solution.

 

You can open both files in a text editortosee whatthe differences are.

 

I don't envy you guys, there are a LOT of things that can go wrong, and it must be a real pain trying to juggle so many tertiary systems that all combine between all the avatars, riggings, animation layers... the head spins thinking about just the existing headaches associated with the fully realized animation system. One can only imagine the pitfalls of wrangling all the new bells and whistles to be better than the prior system.

I won't talk your guys' ears off with suggestions, but I've always wanted to list a few things that always bothered me with my workflow over the years:

This is my current animation setup for the moves in my game (it's gross, I know):

This would be so much more streamlined if I could have just a handful of these nodes set up with global timings and transitions, but if I was able to swap the animations for others in the project through scripting. So instead of having 50+ animations: Dragon punch, monkey bash, twirl smash, etc, etc. If I just had Attack A, Attack B, Attack C, and at runtime could swap out the animations associated with those nodes to cut out the bloat.


This part of Mechanim always confused the heck out of me, maybe you guys could make it more clear what it does or come up with a better solution for whatever it is.

A big bug that always got me, was is if you had a looping animation on an additive layer, and used the T pose in frame 0 (which you have to do so the additive layer behaves properly, don't get me started on how many days it took me to find documentation on this), there was no way to get around that T pose popping in for a single frame and looking horrendous as the animation restarts at frame 0.

Maybe the above issues are already able to be fixed with a proper workflow and I just don't know what I'm doing. It's weird the pockets of information that are out there and workflows that you may or may not be privy to.

Anyhow! Hope you guys are able to pull this off without too much trouble, and not just so us whiney users have a few more toys to occupy ourselves with when we're not screaming at everyone. On the bright side, Mechanim was actually pretty damned good aside from a few nagging issues that i'm sure you guys have heard all about, so at least you have great reference to draw from.

Been farting around in the general forum contributing to the same toxicity that's already in this thread the past week and feeling a bit guilty about it now that I'm reminded that there are actual people working at Unity having to deal with all our crap on top of the most mind melting, unrewarding technical issues imaginable.

Figured I'd chime in with some random well wishes and say that this is one hell of a task you guys are up against, and that it's appreciated. We can only imagine the kind of hell these tools are likely going to be, there are few things as frustrating as trying to manage all these darned finicky animation setups.

Looking forward to seeing your guys' progress! Even if it takes a bit amidst all the craziness.