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.
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.
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.
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.
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.
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.
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?”
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.
Thanks to everyone for your continued feedback, apologies for the delay in my replies.
I actually took much of it and incorporated it into a new quarterly post here
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?