Official Animation Status Update (Q2 2023)

Hi @ChinnyBJ , thank you for sharing!
I'm glad to see the news about the new animation system. Based on my experience using the current animation system, I have some suggestions. I hope that when implementing the new animation system, you can consider implementing these features:

• Graph based animation system
• Lazy load animation assets
• Runtime topology modification
• [Important] Animation sync marker(for pose matching)
• 
  
• [Important] Animation flags(indicates whether certain operations can be performed, like jump, attack, etc.)
• 
• [Important]Per-bone animation processing
• [Important]Runtime animation curve modification

 

I have recently been using Playable to implement a graph-based animation system.



Playable has bugs and lacks many features, which has led me to make a lot of workarounds. Although it is unlikely that new features will be added to the current animation system, I still want to suggest improvements for Playable. And I believe that these features are essential for the new animation system that Unity is developing(hope the new animation system is not just a conversion of existing AnimationClips into another data format, but is a truly feature-rich and brand new system).

This is the Feature Request thread I posted earlier: Feature Request - Animation Playable Feature Requests - Unity Forum

 

Thanks for new update. I'm not expect full complete animation system. Can I get experimental version to try this year to try out first?

 

So mechanim and animation rigging are being replaced entirely in a unified package (or native to unity)?

Alright that's cool.

 

I'll drop by and just say that what's important for me is better netcode integration. Maybe something like Inertialization to minimize the amount of states needed to be synced? Anyways, I'm sure Unity is already looking at multiple approaches to this. If it's fully deterministic then I guess we don't need to go through all that trouble.

Another thing is a better animation event system. There are a lot of issues with the current animation event system but the biggest one for me is that there is no guarantee that an event gets called (cases where time is moved fast or during transitions). The authoring experience for it is terrible too, I have to duplicate the animation clip from the source asset and now it ends up being completely decoupled whenever I make changes to the source. Not to mention the event system's use of strings for calling methods...

 

Alright. Btw any plan to implement auto upgrader from current mecanim animation system to this new animation system that reducing manual upgrade as much as possible? I think at least should able to upgrade animator asset to new animation system asset automatically whenever possible.

 

I hope the new animation system can learn from Animancer.
Especially the simple and direct way of playing animations and not tied to a specific state machine implementation.
https://kybernetik.com.au/animancer/docs/introduction/features#pro-only

 

A few key (excuse pun) things that must be right, just off the top of my head, that there's been no adequate excuse for getting wrong since Flash timelines became a thing in the 90's, but have been long overlooked.

1. It must be exactly possible to be informed of exactly when an animation finishes. This shouldn't be upon the user.
1.a) things triggered on Animation timelines must be exactly reliable, and garbage free, and not C# Events.
2. An absolutely ideally optimised reader of animation curves must exist, and provide low level access, bereft of all other overheads.
3. Stretching the duration of animation curves should maintain the intent of the curve, not the way it currently works in Unity. Learn from splines or any other world where folks stretch time and don't get unexpected and/or undesirable results, how keys should behave.
4. Please don't continue making the mistakes inherent to the way keys have handles screwing with things at the moment, including not being able to pick and edit more than one handle.
5. Draw animation curves in a way that makes them visible. Some of the colour choices in the various timelines defy description, and provide modal selectivity so there's no chance of accidentally moving keys and handles when attempting to select them, and vice-versa.
5.a) make it possible to select and drag the sections between keys for the curving of these segments, that thereby adjusts the handles on the corresponding keys.
6. Make the Play mechanisms for Animation timelines sensible and modern conventional. Learn from the last 30 years of how timelines have been implemented and designed in other packages that provide animation. That includes simple things like "play once" "loop section", adding markers, keyboard shortcuts for keyframe type changes in conjunction with mouse actions, timeline scrolling that makes sense, automatically zooming to fit on input to view a specific curve, saving and recalling viewing sets, selection sets and key sets.
7. Show and Hide and Grouping of Animation properties in the timeline, so as to streamline seeing that which we want to focus on. And have theses states as saveable and recallable, along with colour choices for each property so that we can visually bookmark that which we're focusing on, too.
8. Editable click sizes for the keys and handles, because whatever you choose is only going to be suitable for some screen resolutions and not others, let alone the ways others are accustomed to their chosen animation software.
8.a) recognise that the vast majority of your animation users are spending far more time in other animation environments, all of which are vastly better than Unity's attempts, so make an effort to learn from all timelines in all 3D software, audio software and all compositing software. Pick the best traits and behaviours from these and blatantly copy them. If you can't determine what these are, please hire someone that can to advise. You don't need a committee to do this, just pick one informed auteur.

 

Hello! Thank you and the Unity employees' hard work on the new Animation system, it is a great work.
I know the new Animation is still in developing, but I would like to ask some question, just to get some information that whether should I keep learning and stick to mecanim and GameObject, or should I prepare for the new Animation system and ECS. Appreciate your answer!

1. Is the new Animation system a Component that could be attached to GameObject, or is it forcing us to use ECS?
2. Does the new Animation system also use Playable? Is it compatible with the Timeline package?
3. Is the new Animation system more customizable than the mecanim one (in your opinion)? Because mecanim hides the state machine, the Motion class, and every other things, making it so hard to customize script

 

@Flipbookee Do you think you could pass some of your wisdoms regarding animations in game engines onto these fine folks?

 

hi,

sorry for the intrusion here

but regarding your question whether it will be compatible with gameobjects

i think read somewhere on the forum that they are planning it to be their default animation system for the next 10 years or something, i could be hallucinating too, so don't take my word for it.

 

Unity keep showing off these super high end products they’ve bought - ziva and weta for example. I think a lot of us just need to be able to string together some basic animation clips in a simple and efficient way.
Also if the animation package is going to be unveiled next year that means many of us will have to wait till the year after (for the LTS).
I really hope someone keeping playables alive. It is the most recent animation system after all.

 

There are some great ideas in this video. I hope Unity is able to integrate some of them. Specifically the tooling part of it.

Some interesting ideas that stood out:

• Hierarchical State Machine with unlimited Hierarchies.
• Dual Panel for remembering the context when you drill down into a State Machine
• You can also drill down into a transition for example.
• Instead of having arrows going to every other node for a state machine where every state can go to every other state. There is a symbol that says this state is using a Global State Transition. Then you can have additional arrows for overriding the default Global State Transition.
• Animation Data Sets (Allows you reuse graphs by inheriting from a data set (If animation is not set then that node isn't used. You can also add onto existing data set)
• A lot more interesting ideas about how to deal with some complex problems like resolving multiple IKs, dealing with ragdolls etc.

video:

github: https://github.com/BobbyAnguelov/Esoterica

 

In a perfect world, the animation system would:

• stop using strings for anything. Just take inspiration from the InputSystem and generate ScriptableObjects or generate code - anything but strings. This goes for States, Variables (Parameters) and whatever needs to be accessed
• allow to get a START and END event that is guranteed to be exectued. Everyone struggles with this. Everyone. Please fix.
• allow to get Custom Events that are guranteed to be executed (also not using strings, please)
• have a way to add animations from code. Just like AudioSource -> PlayOneShot()
• get all the informations with a nice syntax that doesn't look like "animator.GetCurrentAnimatorStateInfo(layer:0)..."
• provide ScriptableObjects (or something alike) where it is possible to adjust Start and End Time of an AnimationClip, add Events to it, change the speed and so on. All the options that are currently in the FBX Importer Inspector -> move them over to a ScriptableObject. I have no idea what maniac thought to add those things into the FBX Importer - but for the love of god, stop following his insane architecture.

TL;DR: Nice way to get and set things in the Animator from Code (no strings, nice syntax). Relyable, stable System (Events that are guranteed to be executed). Usability (in code and in the editor, no more FXB Importer Panels, no more strings).

 

I just want (for the last 10 years...) 3 things: a "simple" mode for the animator that doesn't perform like ass when I'm animating just a camera and not a full character. It could even be a checkbox I have to tick or something.

Improvements to the animation window, say you want to have a custom curve transition from one color to another, how are you going to have the transition be exact when you can't edit multiple weights at the same time?

Other software can do it:


Finally, I want the ability to have non linear crossfades, easily. Maybe a sine based one, or just hermite, would improve transitions so much and it should be so easy to implement. I would have been a happy camper if we got these 3 things during the last 10 years....

There are many many other things, but it boggles the mind why someone wasn't hired to implement these silly little things to the current animation systems and instead we are forced to wait for the new systems, which let's be blunt, is not going to solve all the issues people have with the current systems and more than likely will introduce a bunch of new ones.

 

Whilst we wait, could you put systems and reading of Animation Legacy and Animator on another thread, on another core, for all CPUs that have more than 1 core?

 

One narrow thing I'm hoping out of the new system:
- A Mathf.SmoothStep for transitions between clips (as an alternative to the linear default). Have tested those with a not viable workaround and they do make animations overall visibly smoother!

 

As I mentioned in that post, and every other post, not sharing a single detail about that system in public is still incredibly bad. Every time you say "we're making something great, but just trust us on that, and trust us on that we're taking feedback from somebody we swear", it feels more and more shallow.

Look, the animation team has a staggeringly bad record when it comes to listening to feedback. For a decade, people like @Mecanim-Dev essentially called us stupid when we said "gee, the Animator would be a ton better if you just bothered implementing something like

string GetNameOfCurrentTargetState()

".

With the current pace of things, I'm about 80% sure that you'll be shipping something that's absymally bad, in ways that's completely obvious to anyone that's making games in Unity, and that any complaint we have after shipping will be met with "sorry, we can't fix that due to the holy cow of Unity, backwards compatibility".

The longer you develop before you share something, the harder it will be to turn the ship around when you get there. I hope for your sake that you're making something good - Unity can't really take that many more disastrous product launches.

 

Thank you for the quaterly status update, and, with feedback as others have shared here, I'd like to share my opinion on and ask an important question here...

You mention that it is not ideal to put Mecanim on life support.... but if you know it is not ideal, why are you not taking the ideal work step? I'm asking in the critical sense. I believe that Mecanim is within the realm of fixable state as opposed to starting from scratch, inheriting all new issues and lacking in field previously not lacked at. Instead of having 6 incomplete solutions, have just one and make it the best it can actually be from all perspectives authoring, runtime, and UI. ('6' coming from looking at rendering which includes BIRP, URP, HDRP, Custom SRP, URP 2D, and Entities Renderer, as an example)

It is not to say that I don't get the pursuit of the newest and shiniest thing but with how long we've been waiting without reveal or availability to give meaningful feedback on current states, the current trust that Unity will ever have an 'ideal' animation system is very low, from my POV. I am sharing this because I want Unity to have a good animation system, and I want it to succeed.

Please make steps for the betterment of usage by actual unity users, and not just what is less painful as the developers behind the internal veil (which we are at the mercy of, because internal code is literally beyond our means to edit and improve on)

With that out of the way, I'll bullet point some of the more critical thoughts on Unity's current animation system and my woes with it / wishlist.

1. The biggest frustration right now is read-only animation in Unity, and the lack of good workflows around it. The FBX importer generates animation assets from scratch every time, which means you cannot make meaningful additions easily. I understand that it respects the source FBX file, but it literally locks us out of doing anything useful with the animation such as adding curves for enabling and disabling visual effects, specific gameobjects, or authoring anything easily. Making a clone of the read-only animation is a destructive step that is simply unacceptable, as proper experience requires the ability to iterate when working with any digital content creation tool like Blender, Maya, Cascadeur, or whatever else. Locking the animation to Unity with animation cloning to a unity .anim file has not once been a viable solution for me. Let us add new curves easily, make the animation window work, figure out how to store this in the fbx importer's metadata if you need to.
   
2. Make it possible to add new types of animation events, such as paired animation events - often used for flagging an animation with specific information, so that we can guarantee 'stop' events come after 'start' in case of a mid-animation abort. This has been painfully unreliable, and while I understand where this implementation comes from, it is simply painful in its current state.
3. Make us able to preview animation clips in whatever state machine or alternative solution we use. The Animator Controller window, on inspecting an Animator State, will not show a preview of the animation clip even if it is just a simple motion. This is painful as it means you cannot time things easily with state machine behaviors.While I managed to replace the preview window for it myself with some hackery, but it would be far better if it was just a native feature in Unity. For whatever system that comes next, consider ease of authoring things - always allow easy preview of what you're working with.
   
4. Make reliable animation events. By this I mean make events that force re-evaluation of the track at their specific timestamp. Right now Animator defers calling events until it finishes evaluation at whatever time it reached, which means the time the animation gets called at is unreliable. If you make a clock that has cogs showing time and you have it print the time on 3/6/9/12 you will be at the mercy of deltatime and get animation events like 3.04 or 9.1 depending on how fast it is, which means you can't reliably use the sampled animation for gameplay like shooting projectiles in specific directions based on the sampled animation at the time of the event. For animations that have pivotal branching moments, this is even more critical. Let events force a resample at their exact time stamps. Even if it comes with warnings - a user that flags an animation as reliable knows that they need it. Unreal Engine has this, for what its worth.
   
5. Lazy asset loading / addressables. I know that we can use playables to dynamically bind animations using addressables, but the integration with Animator is incredibly poor. Whatever system comes next should be far better. I want to easily be able to author a group of animations and how they should be used while enjoying the benefits of addressables for said groups. (E.g. a set of weapon animations, magic combos, and locomotion, should be loadable together dynamically, each maintaining their own dynamics)

I also agree with others that motion matching, code generation hard-typed animation information is incredibly helpful, though for myself they're not a critical feature. What is critical is the capacity to work unhampered by secret system limitations or bugs, and not have time wasted.

I also dread the 'Humanoid' retargeting system and how nothing wants to support it. This deserves its own set of bullet points. While it would be incredibly nice to have a perfect humanoid system, I'd honestly prefer simply not having one in unity if the alternative is as sub-par as the current.

• First off humanoid typed animations destroy the animation curve keys for a specific model. There is no way to cleanly restore a connection between a bone and its humanoid named counterpart in the curves. This must not be repeated in whatever comes next.
  
• Secondly because the curve connections are destroyed, nothing in unity seems to properly support humanoid animations, including the FBX exporter, which is crucial for iteration. If I author an animation and edit it with humanoid mode enabled, and want to export it for an artist... the FBX exporter by unity itself literally cannot do that. I had to roll out my own solution which was infuriating at the time.
• The humanoid structure has no good authoring quality of life, you can't see an animation playing on two humanoids side by side to compare them and see whether tweaking their humanoid options affects the animation in the desired way. This needs to be provided in whatever comes next.
• The humanoid bones list does not contain prop bones. This means that tool usage is completely unachievable with good quality, any held stick that needs tilting in any capacity goes is doomed to look subpar... which is ironic, because the tool-using animations are what sells best on the asset store.
• There is no way to provide your own bones to retarget / name for the humanoid system to solve. If we had that we could add our own prop bone expectations, but that's not in. Even worse, if you want to add a custom bone path for the avatar, you can't expect it to work, because the entire path is sensitive, you have to make sure every bone down the chain is named the same. I have not found a single proper recommendation to overcome this short of re-targeting the animation outside of unity, which brings me back full loop to read-only animation woes at the previous bullet points list.

Lastly, the ability to do mirroring of generic animations would be nice. Not a must.

I hope whatever comes next for animation will be amazing and take all this into account.

 

I'm guessing higher up manager mandate / it's not his call.

 

To phrase the first part of this post a little differently, since it's obvious that the primary goal of this new animation system is to provide a full DOTS-integrated solution, I think that instead of:

The real question is "Why not DOTS-ify Mecanim so it still works with non-DOTS projects, but also benefits in full-DOTS projects?"

 

Also VERY curious about this question - it's pretty tiring to keep getting new systems that don't roll out with automated upgrade tools.

 

The most disappointing thing is that the Mecanim animation system is not sufficient to support complex animation needs, with numerous bugs. Unity has focused its main efforts on DOTS Animation, but it seems that DOTS Animation is still a long way from being available. And we don't even know what the functional differences are between dots animation and the current animation system.

 

Oh yay, a new system no one asked for that won't ever get finished before half your team gets fired or reshuffled by your executive board.

Besides my glib comments, I reported a bug specifically affecting the 2D workflows. This new system sounds heavily focussed on 3D animation. So we'll still not be seeing fixes for any issues affecting the 2D workflow, while a new workflow is developed that currently is not considering the needs of 2D usage?

Will the new system even be compatible with existing systems, such as playables?