Animation Status Update (Q3 2023)

During the traditionally quiet summer season, many of you have added some great comments and questions to my last update , along with some understandable uncertainty , skepticism and impatience to know more details.

I actually started trying to build individual replies to everyone’s questions (attempting without repetition) but instead, I thought I should try and at least pull out some common threads otherwise things might get muddled.
Then it made more sense to bundle this into another quarterly update, for wider visibility.

I will preface this with the fact that I can’t always answer all of your specific questions, requests or complaints, but do acknowledge them, while I try to address some of the bigger questions.

Mecanim’s status
Mecanim is not going anywhere and we will continue to support it. But SolarianZ does point out what is at the heart of the matter for Mecanim, mainly that it does not manage complexity well. That’s because it is a bit old in software terms. The architecture was laid down around 2009 and it was first released in Unity 4.0 in 2012, for comparison Unreal was still on version 3 then. So yes, the current animation architecture, while originally flexible, is now comparatively limited, and is certainly not capable of scaling to the complexity needs of future games, or for the next 10 years as ThynkTekStudio mentions. Now, Yoraiz0r quite fairly posits that we might be able to fix Mecanim, which is something many of you might also be wondering. I am not sure how many of you know, but we still have original Mecanim architects in-house and after a serious amount of investigation, we know for certain the amount of work to rearchitect or DOTS-ify it in place, is well, FAR bigger than building on the new DOTS architecture.

Yet another additional system?
Yoraiz0r also highlights a common complaint that we have multiple competing systems in many areas of Unity. I agree with this, as well as with the statement “…have just one and make it the best it can actually be from all perspectives authoring, runtime, and UI…
We thought we could eventually do this when we released DOTS animation…early. Many rightly said way too early, as it was incomplete and pretty much an all-or-nothing proposition in a pipeline. We have been a bit guilty in the past of over-promising and under-delivering, not updating quickly enough, and even abandoning solutions some are using in production - albeit usually experimental. I agree we should eventually “just have one” but we don’t want to make the same mistakes I just mentioned, knowing that managing multiple competing Unity systems, and packages in different states, across multiple Unity versions, is untenable. So…

In an ideal world…
There have been a couple of remarks related to my “not ideal” comment in my last post. Well, in an ideal world, I would love it if we would fix every bug and the little things , add improvements and new features to Mecanim, AND build a new animation system on DOTS, all at the same time. So, AcidArrow is partially right in that while ultimately it is not my call alone, it is certainly a collaborative matter of setting priorities and resourcing. Given this, we believe we are working on the ideal next steps to ensure the future of animation at Unity will exceed your expectations. So let’s dig into that.

GameObjects vs ECS
Yuchen_Chang asked about GameObjects. I did mention here that yes, you will be able to continue using GameObjects, and that we won’t force you to use ECS. However, we do expect that if you are undertaking something of considerable scale then ECS will be best suited to that scenario, while continuing to coexist with GameObjects at the same time.

So it should really do…everything?
We really do listen, even though some might think we are developing in a vacuum . There were a ton of valid requests, requirements and different perspectives from the last thread alone. Here are just a few.

saskenergy touched on the need for better netcode integration.
nickdollahz points to a very interesting video about Animation Graphs and Hierarchical State Machines, and much more
SolarianZ has suggestions , including for graphs, markers, and flags. As well as the issues around Playables , which is really tied to Mecanim, so poses as yet another system to somehow support.
Unification starts with a key pun on overlooked timeline features
kvfreedom hopes we can learn from Animancer as a simple and direct way of playing animations. I completely agree this fills a need and is high on our list to review. But perhaps more importantly, is also making sure Asset Store creators have continued success with the new system.
optimise and deram_scholzara want clarity on automated upgrading, which I honestly believe is far harder than anyone might think, and might not be possible.
Yoraiz0r goes into great detail about Humanoid . It is popular but has not aged so well, even though we know it is widely used, it has some severe limitations, which is why we have Generic…which is yet another competing system :frowning:

As a microcosm, this amply illustrates the breadth of our challenges.

Animation is in every game, and the needs are varied and endless it seems. We recognize that there are many people and disciplines that touch animation in some form, in every game, and we know that there are common requirements that every production encounters. It is these we want to make sure are bulletproof in production. In an ideal world, we would complete everything for the first version of the new system, but we know that is probably too big an ask. However, when we do deliver, it absolutely must serve as the foundation for all productions! Be approachable for those who use it every day, and it must be easily extended on demand. Once out, it should very quickly expand to deliver on all production needs

Challenge accepted!
The recent feedback has been great. It has helped shine a bright light on the many broad requirements we are undertaking.
So, now we know we can’t realistically evolve Mecanim or just have a DOTS-only solution, and that the new system must continue to work with GameObjects, and easily scale, elegantly handle sophisticated characters, and manage future complexity. It must be comprehensive and not just another competing system to juggle, one that is not half-finished, but ready for production now and for the next 10 years. It should be highly customizable, unquestionably performant, multiplayer ready, have extensive authoring and runtime capabilities, and limit the need to rely on 3rd party plugins.

A simple summary might be, make it “fast, flexible, friendly and future-proof”
A simple answer to what is Unity building, is “All of this”

Needless to say, we likely won’t be able to do absolutely everything out of the gate, which won’t please everyone. But we absolutely will ensure that whatever we release, is ready for any production.

Why not just share what we have?
optimise reasonably asked if there was an experimental package ready. Simply put, no it is not ready. But when we do have one we will of course be extremely keen to get your feedback.

An exercise in patience
We are very aware that it has taken longer than we expected, and hope that you will continue to bear with us as we endeavor to prepare this significant advancement.
I have no doubt that the questions and comments will continue, but hopefully I have given you a bit more clarity, as best I can, on the past, present and future of animation at Unity

Chinny
Product Manager - Animation

PS - a bit of other news we just posted a blog about Unity 2023.3 and started a forum post

22 Likes

Hi. I would like to know when this new animation system will battle test with dots netcode internally that able to work nicely with dots netcode without any issues and animation glitches? I expect the first experimental version of new animation system will support dots netcode by default

2 Likes

As I mention here we don’t expect it this year, but do expect it to work with netcode, hopefully without any glitches :slight_smile:

5 Likes

Thanks for reply. I would like to give feedback that new animation system should able to make it able to integrate dots based game logic together with new animation in much more streamline way that developer able to create custom block to put game logic and link the node graph together with animation. So basically game logic and animation are blend nicely together

1 Like

This is a good post, you addressed a lot of stuff and it seems you are saying the right things, I just don’t think you can “promise” the one thing that I think is Unity’s problem in general (and also specifically for animation stuff).

It’s only old because you (the Unity “you”, not you, personally) let it. The only “major” feature the animator got along the years was being able to zoom in and out in the controller, everything else was mostly maintenance.

And it really doesn’t matter what I say (and I think I’ve already said a version of this, plus I probably won’t be here to see the new animation stuff if / when they release so whatever), but you (this time, you personally), can’t really promise that Unity will properly support and evolve this new animation system for years to come, this is a “Unity” call to make, and all I get from “Unity” these days is “wow, aren’t movies and tv shows and AI so cool?”.

1 Like

Thank you for yet another quarterly update, and for acknowledging you’ve read our individual posts!

I am rooting for you through the tasks ahead, and will be trying whatever comes out as soon as I see it - much as I have tried with related tools (DOTS since initial release, MPPM which I can’t get enough of, and even Playables & FBX Exporter)

In regards to Mecanim, I’ve recently experimented with some few things I think are easy improvements or additions (read: I’ve looked through the unity CS reference and also attempted reflection hackery to achieve certain behaviors). You say that evolving Mecanim cannot be done yet it will continue to be supported - is there some clear distinction for support vs evolution?

For example, right now if you have state machine that has its layer default state in a substate, the StateMachineBehavior.OnStateMachineEnter / OnStateMachineExit don’t get called as you press play. This is slightly vexing, because you cannot set a ‘substate machine’ as the default. For example, consider this:


The documentation rightfully points out that the OnStateMachineEnter & Exit do not get called in the event of entering a state directly, but there is no option to begin with a state machine ruining this workflow. To solve this, the only solution at this time is to hack it with something like so

Would this fall under support, or evolution? Alternatively, did I miss anything that allows a Mecanim state machine to begin without a default state so it can properly go through the state machine behaviors OnStateMachineEnter for its initial state?

Similarly, Animator State inspector currently does not show the animation clip’s preview, despite the fact that it does show preview for Animator State Transitions, this baffles me. It looks like it would be the most natural thing in the world to have - so I hacked it into existence. If this can’t be brought as a quality of life improvement for the current Mecanim in all projects, can you please at least explain why?
Example: Note that normal projects do not have the preview portion.
y8vfwo

(The ‘showing animation solo’ is debug information for my own usecase… because I overrode the entire animator state inspector just to get this preview window going. Not fun)

I hope the animation team can at least address simple and intuitive changes like these please - if there is not going to be a delivery of a new, far better system, anytime soon.

Cheers for whatever the animation team intends to put out, and for Unity 2023.3.

This is an amazing goal to have but please do not fall into the same trap Input System did. I elaborated already [here]( https://discussions.unity.com/t/925940 page-2#post-9222468), but basically, don’t ever build high level solutions (like motion matching if you ever will want to have that) on top of low level stuff that is not exposed to the user.
I really hope to see multiple levels of API from low to mid to high level so one could go as deep as they want when trying to modify the system behaviour. And also keeping in mind other principles from Casey Muratori’s talk on API design like less callbacks… Which unity seemed to do back in the day more than now

So package is not ready, but hopefully it doesn’t mean you can’t still improve engine level APIs? Like allow to read animation curves at runtime and not as editor only API for seemingly no reason…

Also, by not requiring ECS hopefully this means we won’t need the ECS package? Cuz honestly I’m not very interested in backing workflows those guys have :roll_eyes:

All that said I’m glad to see more and more communication coming from unity devs that actually sounds reasonable, thanks for taking your time to write all of this.

3 Likes

Wow…

Considering what happened with other tech anim systems and packages from a few years back, personally just want to pull it off, before it is too late, you know.

:wink:

As the guy who stuck at 0.9.0-preview.6 from 30 months ago, I reckon there’s no way to upgrade to what’s coming next from there, even in a manual way, right?

–edit again–
All I’d like to say is, Dots anim 2 years ago was already there and not bad, it completed every functions and features my game required(1st person anim, 3rd person anim, body layer and IK…), in a tough way of coding though.

–edit–

Don’t worry, I already moved on and Dots anim is always my first love : )

2 Likes

Hi @UnityChinny ,

I can understand that you are not able to tell everyone when the new animation system package will be publicly accessible. However, can you provide some information about the main features of the new animation system?

I believe that people who are actually using game engines to create games may have a better understanding of animation needs than those developing the game engine itself. By sharing a list of features, you can gather feedback from users earlier on.

Thanks for your insights. The “tough way of coding” is something we were told repeatedly.
As for upgrading from 0.9.0-preview.6, no, that won’t be possible, sorry.

We can’t talk about a feature list just yet, sorry about that, but we will share more when we can.

It is a fair comment regarding the difference between game engine makers, and game makers, however we do have a lot of game production experience on the team, and as I mentioned here we are not building this in a vacuum.

The package is not finished, nor are the APIs, so they will continue to evolve :wink:

As for the ECS package, I am pretty sure that will just be required to be installed at least :slight_smile:

Thanks for taking the time to highlight this.

In terms of evolving Mecanim, we are always focusing first on fixing crashes, blockers and regressions etc, at the same to time we do review every issue and request that is logged. I can’t speak to your particular case, but if it ends up on our system then I will review it with the team.

Note - There is no clear distinction on what we will address, but if there are workarounds or “hacks” then we probably won’t address it. Whereas simple changes and improvements or updating the API might make it in, as we make a determination on a case by case basis, as every request is different.

1 Like

Firstly, just for animation, the breadth of requirements is vast as I pointed out. So this vastness is amplified for the entire engine. I believe Unity has made amazing tools and services available over the years, which should be considered a success.

However, sure we have made some mistakes, and this is honestly pretty unavoidable when making software on this scale
But we (the company) have always had the best intentions and best interests of our users at heart, including trying to be as transparent as possible when we can be. This meant that sometimes we were not able to deliver on our promises, which sucks for everyone.

Secondly, yeah this talks to the skepticism bit I mentioned, and you are right, I (personally) can’t really promise something that far into the future, but we (the company) want to continue aiming for success and learn from our past mistakes whenever we can.

Lastly, Unity is used by customers in many other industries outside of games, and there are other emerging technologies which which perhaps get over-hyped, so sometimes might seem we are not focused on games, but this could not be further from the truth.

1 Like

:frowning:
I’ve heard that ECS increases domain reload times by a lot and slows down editor as a whole. Was kinda hoping new animation system to be somewhat similar to ECS physics which doesn’t actually care for ECS and one could hook it even to GameObjects (which still needs ECS package but you get the gist)

But in case I’m wrong about ECS package overhead then all good as long as noone forces conversion workflows

1 Like

Generally as someone brand new to the current animation system, it seems tilted towards 3d and characters. I would love some creative flexibility, something like an animation synthesiser where math expressions can easily be blended with keyframes with little additional code. Running multiple states on a single graph to keep track of signal flow. Blend tree assets…one can dream.

1 Like

this isn’t going to be released as some animation helper tool?

The worst part about all this is that all of the every-day animation systems are in complete stasis while this is being developed. So the sheer lack of any info on how things are progressing or even a vague timeline is just increasingly frustrating.

Definitely want to say good luck, though! This is a big undertaking for sure, I just wish there was more communication than a once a quarter “we hear you” post.

Just use Cascadeur.

1 Like

okay, but unity’s one is different. it has physical collisions implemented, already inside unity, so…
might be used as animator post-process…