You know I’m not the wishy-washy type when it comes to provide honest and sometimes harsh feedback and there is a very little chance that it will ever change. But thank you for this post, I much appreciate that you took the criticism on your last post and changed up the structure and focus of your update. It’s truly great, even if it’s not a commitment. This way we can discuss the things matters instead of the seemingly inevitable shortcomings of the leadership.
There are people who can and will or did better provide feedback of the more traditional way of animation. But about…
This tech is great, when Unity first started to push it, I was happy to see it because it makes things easier to everyone, including designers, it is far easier to label animations than put them in state machines and timelines. And obviously as a (software) developer, search engines are always interesting and more powerful than a timeline or keyframe-editor ever can be.
The main problem with MM as you stated is the questionable animations. What Unity could do instead of Muse Animation is to utilize your special relationship with publishers and support cheap or even free animation sets to provide indies the most often used standard set of animations. Prepared for motion matching, including the intermediate small animation-bits, tagged appropriately, etc.
What I saw so far about Muse Animation is that it is a very dumb MM engine. I did not see any bit of new animation created by the engine. Where there was no sample, it fell back on some other animations instead of create an appropriate one.
So, no, Muse Animation won’t be for the rescue. As of today it is a dumbed down MM engine. Besides you will HAVE TO provide ways to avoid any generative AI shenanigans regardless. So I urge you to make the standard stuff ironclad and then you can play around with AI as much as your heart desire, but do not put any emphasis on it, I beg you.
Animation Events with custom payload would be nice. There’s plenty of times where it would be handy if I could emit two floats with the event, or whatever.
Animation Event “blending” like how curves work where if all the movement clips have a “footstep” event on them, only play it for the clip weighted highest or something, instead of spamming multiple events in a row for each of the clips like it currently does.
Transitions with any time between option. Right now I have to make several transitions with Exit Time after the point to hopefully catch it, when it would be nice if I could mark a certain range where the transition’s Exit Time can take place.
Transitions with or conditions. Right now all the different transition conditions have to be met, but it would be nice, for examples, to say if turnAngle > 45 or turnAngle < -45 instead of needing two transitions for each option.
Have variables for everything from Transition Conditions, exit times, transition conditions, Blend Tree values, etc. It’s very common to use the same float value in multiple places in when adjusting transitions or blend tree x/y weights, so it would be nice if I could extract those out into a couple different variables to make bulk tweaking them easier.
Better tools around Animation Curves. I would love if I could bulk copy/paste them from one animation to the next. It would also be nice if Unity could generate Footstep, LU, and RU curves for bi-pedal humanoid animations.
Better support for match targeting. So if I’m playing a vaulting animation, I can say at this point in the animation, the player’s left hand should be here and the gameObject moves to the correct position during the vaulting animation for me.
Better support for tying sounds, particle systems, script calls, etc to different parts of an animation. Right now I abuse AnimationEvents for this, but there’s no easy preview like there would be in timeline.
Better organization for Animator Parameters. My character has about 50 different parameters right now, so it would be nice if I could group them and put them in subfolders or something.
Have a callback in Play and CrossFade for OnComplete.
Better support for state machine behaviors on sub-state machine. If I add a behavior to the parent sub-state, it gets copied over to all of the child states. Unfortunately, if I have an OnStateExit there, it will fire when exiting each of the child states instead of once when it returns from the whole sub-state machine.
Ability to have a Timeline Clip Playable as a state instead of just AnimationClips or blendtrees. Timeline makes it easy to add and preview sound effects, vfx, etx. Would be nice to use all that in a state instead of just a clip and hope AnimationEvents tie everything together.
States should be able to have AvatarMask override instead of that only be available at the layer level.
Avatar Mask limb weighting % instead of mask being all or none.
Ability to turn off animations for specific bone chains so you can do things like have the right arm be ragdoll but the rest of the character plays the regular animation.
Ability to sync normalized time of several states on the same layer. It would make transitioning from a movement blendtree or different weapon specific movement blendtrees or crouch movement blendtree, but keep feet synced up nicely between them all.
And last of all, please make an easy way for me to get the name of the current Animation State!
I’ll update this post when I think of anything else.
I would like to see a better UI for the Animation events. The problem with the current UI is that you cannot zoom in on the Events in the Events timeline, which makes it hard or impossible to place those events.
The events on the timeline are so close together that selecting and moving them is tremendously error-prone and frustrating. Being able to zoom in/out on the event timeline is required to adequately place animation events.
A regular programmer could probably improve the animation events UI in less than two weeks and it would greatly improve the quality of life for people who work with it. I see it as low-hanging fruit: little risk with big QoL impact
The more similar request like this one came up, the more likely the old animation system was hit the limit
This actually better handle with Animation Job System and we could write any complex logic and take any variable to transition with C# code. Or better be an ECS node programming, like a shadergraph or VFXgraph but being ECS
And then we would realized we should have ECS path for VFXgraph to make it work on various platform without compute shader
And then it become the same system. VFXGraph is just another kind of animation and physics, same as animation transition from clip to IK and ragdoll. All should be handled in grand unified graph system
I would love default events you can subscribe to in each animation for clip start and end points. I’d also prefer being able to get a reference to an AnimationEvent and being able to subscribe to it with C# Events as opposed to SendMessage, since it feels a fair bit cleaner code wise (It would also likely be faster, though I don’t know for sure).
For what it’s worth, that’s already possible to do but isn’t the cleanest process.
If you pick any state in the Animator Controller, you can press “Add Behaviour”, this will get you a template of a State Machine Behaviour with a reliable Enter & Exit State methods you can write whatever code you want in. If you want to grab those SMBs at runtime and give them scene references, just use Animator.GetBehaviour<YourSMBType>().
You can also make events of your own and add them at runtime, get the animation clip and call AddEvent(yourEventInstance), they’re regular C# classes so you can make any event you want, though they still go through the regular string messaging system… there are some cool benefits. You can set the event to not require a receiver so it won’t complain if there’s no component that can use it, and you can assign the object reference to any unityengine object class.
The process is still convoluted, just hoping it helps until the new animation system shows up and (hopefully) makes things better.
Yeah, the preview capability is incredibly important. In Unreal Engine you can also see the effects actively playing in preview with scrubbing back and forth, like Unity’s own timeline. The only reason we can’t use Timeline properly here is because the animation tracks only author in absolute world space and not in character space… wish that changed.
My primary concern is to have safe and robust script-driven animation transitions that respect the animation designer’s intent as much as possible.
I think the node graph is an excellent interface for the animation designer to intuitively set and adjust transition parameters and visualize it, but there are too many problems with Mecanim’s design.
The biggest problem with Mecanim for safe transitions is that neither the animation side nor the script side can take control of state transitions, which requires very sensitive synchronization.
This is not an easy problem to solve by using an exclusive trigger for all Mecanim conditional decisions.
The following specifications are particularly difficult to synchronize.
Firstly, it is necessary to consider the case where multiple transition conditions are satisfied in the same frame. If the order of the conditions in the animation and the script are different, they will be out-of-sync.
As the overall view of the node graph does not provide this information, it is necessary to carefully check the order of each condition by clicking on each transition one by one.
Next, transition times must be considered. By default, Mecanim does not judge a next condition during a transition, so if more states on the script side attempt to transition during that time, they will be out-of-sync.
It is necessary to ensure that the script-side state time is greater than the transition time, or select NextState in InteruptionSource.
This can introduce bugs that are difficult to detect because the script-side state time can be variable (e.g., from jump to landing), or the game designer can adjust the time parameters, and InteruptionSource makes transitions more complex and more difficult to understand.
Then, Animator’s update mode must be considered. For example, if script-side state transitions are done in Update and animation updates are done in FixedUpdate, FixedUpdate can be called multiple times for Update, or it can never be called, and that alone will cause out-of-sync.
The validity of the script will depends on a setting outside of the script that is difficult to notice.
Finally, it is necessary to consider that Mecanim only allows one state transition per frame.
Basically, a script state transition involves many interactions between actors. In a basic implementation, a script state can transition multiple times within a single frame due to these interactions.
For example, consider a state machine that can transition from state A to state B and from state B to state C, but not from state A to state C.
Suppose a script transitions from state A to state B and then to state C by interaction request within a frame, but since Mecanim only allows one state transition per frame, the transition from state A to state C is not possible and they will be out-of-sync.
If you try to handle such cases in Mecanim, the node graph becomes even more complex, diverging from the script’s state machine and making it difficult to understand.
On the other hand, if you try to control the exclusivity of interactions in the script, you will have to struggle with the priority of interactions and execution order of the scripts.
And because these bugs occur when multiple conditions overlap at a particular frame, they are hard to notice, hard to reproduce, and hard to pinpoint the cause.
Why should we have to consider such complex synchronization and be limited to software design just to play an animation?
I offer the following suggestions to solve this problem.
One is to provide an option to separate Animator’s update and a conditional judgement API.
By calling the Animator’s conditional API in response to state transitions on the script side, synchronization is guaranteed as long as the structure of the transition is the same.
(Ideally, Mecanim’s transition conditions should have a special condition established only by the script.)
public bool RequestInteraction()
{
if (state == State.B)
{
StartStateC();
return true;
}
return false;
}
void StartStateA()
{
state = State.A;
timer.Reset(1f);
animator.OnConditionEstablished("Base Layer.StateA");
}
void StartStateB()
{
state = State.B;
timer.Reset(1f);
animator.OnConditionEstablished("Base Layer.StateB");
}
void StartStateC()
{
state = State.C;
timer.Reset(1f);
animator.OnConditionEstablished("Base Layer.StateC");
}
void Update()
{
switch (state)
{
case State.A:
if (timer.IsEnd)
StartStateB();
break;
case State.B:
if (timer.IsEnd)
StartStateA();
break;
case State.C:
if (timer.IsEnd)
StartStateA();
break;
}
}
The other is to provide an API that guarantees the animation always reaches the state specified by the script.
By having the API search for and apply the appropriate transition parameters from the current state to the requested state, we can guarantee synchronization while maintaining the natural transition set by the animation designer.
(It would be better to have a fallback feature to select a next best transition parameter if there is no transition set.)
// pseudo-code
void CrossFadeSmartlyIfNeeded(int targetFullPathHash, int layerIndex)
{
var lastState = IsInTransition(layerIndex) ? GetNextAnimatorStateInfo(layerIndex) : GetCurrentAnimatorStateInfo(layerIndex);
if (lastState.fullPathHash == targetFullPathHash)
return;
CrossFade(targetFullPathHash, layerIndex, FindBestTransition(lastState.fullPathHash, targetFullPathHash));
}
I think we need an alternative to animate other than the state machine. However, my impression is that some developers dislike Mecanim’s design, which is difficult to synchronize, rather than the node graph representation itself.
If a state machine that is easier to synchronize can be developed, I think more developers will use it.
That being said, most of those problems could be alleviated by having the animation state machine drive the logic of the characters. So instead of having to sync two sources of truth about which state the character is in, you’d have the animation state in control of everything.
That is a very nice idea in theory, and Mecanim will fight you every step of the way if you dare attempt it. The API to query “what state am I in” is horrendously wordy, slow, undocumented, and string-based. Maintaining an API to poll the animator is a nightmare, and the animation team has not thought that that was important enough to fix for a decade.
This is, I think @UnityChinny , one of the big fears I have with whatever you’re making. It has never been possible to get into the head of anyone that has the power to make decisions that being able to poll the state in Mecanim without tearing out your eyes is actually important. How do we know that it won’t be exactly the same in the new system - a million features of varying quality to do different kinds of state blending and IK, and no consideration whatsoever for “what if the users wants to check if the crouch animation is playing?”
The problem I see with Mecanim is it is so easy to blur the lines between gameplay state and animation state. People forget that animations are a skin. When you have animation system trying to make gameplay decisions you run into problems with trying to keep things in sync. It is hard to reason about. It is hard to change. Although most of the time you end up in a situation where some of the decisions are made in the animation system and others in the gameplay system. This is what is so nice about Animancer/Playables is that is allows you to directly control the animation via code within your gameplay logic.
I would argue in a perfect world you can rip out your animation system and replace it with a blackbox with timers. So you can tell it to enter some state. It tells you when that state is complete and other tagged events as well as root motion delta\when in interruptible part of the animation. The gameplay system should be the thing directing the animation system.
I would propose a deterministic animation graph which is designed to generate a list of commands that generate a set of poses. This can be in the form of a hierarchical state machine. Each state is basically a set of nodes that generate a series of poses over some time span. Things like IK pass, Motion Matching, Blend tree, animation clip, masks etc. This composition-based approach will allow the user to build any kind of animation they want. You formalize things like multiple ik passes with multiple blends in an easily readable way. There are lots of things you can do from a UI perspective to communicate this clearly as well. See the attached videos. There would be very little to no transitions in the animation graph itself. There also needs to be a concept of sync time in the animation graph.
So, in a multiplayer environment you would replicate the list of commands that make up the state you are in and the timestamp as to where they should be in the generated animation.
Pose: a set of transforms for all the bones in a skeleton
A game that have state and drive animation just to show something to express that state to user, such as turn based or strategy game
And a game that want dynamic physics and animation. The pose of the character itself is a state of the game and animation are driving that. Such as in real time action fighting game or platformer. Hit box presenting or absented are tied with animation
There are nothing wrong with these difference approach but I think the problem is we used mecanim to try to fit both case and it’s not flexible enough for both
I’m not sure I fully get your point there about turned based and strategy games. I’m hoping you can elaborate more. In the system I propose you can still build simple state machines. Just only use the state machine nodes.
Either way I would think you would still have some rules set in code somewhere for your game. I would argue that is the best place to drive the animations. What I imagine what you are referring to is you have bunch of animation parameters that the Mecanim state machine is checking to know which state to transition to. I would argue that code should be with the gameplay logic. This way when the gameplay logic changes you can change the animation logic as well. The animation system should only be responsible for displaying the animation.
Instead, what I see is the Mecanim system checking all these variables which leaves room for errors in which your assumption about what the state the state machine is in is no longer in sync with your gameplay logic.
People forget that animations are a skin. When you have animation system trying to make gameplay decisions you run into problems
That it was not really a problem. It just a difference kind of game
What you are mentioning here is most likely a kind of game that I would like to say closer to strategy side. Which is perfect for most game
But some game was not fit for that. Game that want realtime physics interaction and similar minuet details, animation will affect and can become decided factor of gameplay. That’s when state machine also affect gameplay logic and it can’t be helped
@UnityChinny thanks for the update. I have a better idea of the direction the new animation system is taking. I know that the plan is for every GameObject to have an entity. I am still not sure what form the new animation system will take or how it will interface with ECS and MonoBehaviour. Or how multiple ECS worlds will be handled. I assume it will be a Mecanim replacement with a GUI presentation layer.
We are working on a lockstep networking game using ECS, so determinism is important for us. I would like to share some of my thoughts on what is important to us.
-Determinism is important (same input same output on different machines)
-As far as prediction I am not sure how realistic that would be. Often animated characters use interpolated anyway. Multiplayer games will never be perfect and sizable discontinuities can arise. Being able to handle the discontinuities via blending would be very useful. However, I see something like this breaking determinism. Even so, if kept in a separate non-deterministic presentation world, determinism could be preserved. The same technique would be able to handle discontinuities from either mispredictions or interpolation rollbacks. When blending between the old and new state Motion Matching could even be an option.
-Being able to move around skeletal animated hitboxes in a deterministic mode, without overhead from graphics, will be important for headless servers and separate deterministic ECS worlds. Actually, for determinism only hitbox position matters. The animated mesh itself can be nondeterministic.
Would definitely appreciate better polish on the tools for the new system, with less hacks to extend the functionality. But if possible being able to do code expressions on parameters similar to After Effects or an easier way to do more generative elements would be super cool.
I create AR experiences and would prefer a system to serve broader RT3D creative media options and well as games.
Personally I am a programmer at heart although as a one-man indie I have to try and turn my hand to everything.
The animancer package is my answer to all the issues above with mecanim. For my current project this works brilliantly. So I guess my main feedback would be: please make sure any new animation system you implement is fully controllable by scripting because in my limited experience this is a much, much better method than trying to build state machines in the UI which then overlay into game logic.
Also, can we have the ability to retarget animation clips to different game object bindings at runtime please.
I tried Animancer, used it for making animations play with a controller built ontop of KinematicCharacterController… it worked however I generally can’t stand doing anything to do with controllers and animations… it seems like the worst and most unfun part of making a game also kinda the most complicated and yet so key to having an actual good game with character and animations that interact with the world. Making it work with multiplayer is just another level of complication to it.
Which is why I’m looking at Unreal 5.4 and its new animation stuff with complete jealousy, complicated stuff made a bit more simpler to achieve, if that stuff isn’t in Unity 7 then you’re gonna start losing people. As much as I like Unity and familiar with it and c# preference, it is slipping behind, not just in this area… but also world building and rendering performance of such large worlds…world partitioning built in, nanite etc you get it… it’s just a lot faster and quicker to do that stuff with the tools that come built in compared to attempting it on Unity and half a dozen assets to try make work well together.
“Even if we only limit ourselves to mobile devices in the future (see above) in a few years time”
yeah well it kinda feels like this engine has set itself up for that kinda future looking back over the last 6 years with the competition all catching up and surpassing various areas.
I still think it is a good idea to not let the animation graph make gameplay decisions. Especially if you are trying to do multiplayer. As now you have to replicate the animation graph as well.
Although moving on to another point I wanted to make. Seeing as how Godot and Unreal both have similar Animation Graphs that generate poses. I don’t see why Unity should do anything different. One thing I will say about Animations Graphs you introduce some complexity in the form of a new visual language in which you have to program the graph in. So those sets of nodes, parameters and transitions will have to be powerful enough to handle all these different kinds of games.
I like to think it as the animation graph decides how to transition to different states but the gameplay system will be deciding which state to transition to. (ie. when player press jump button go to jumping state)
Something like a new low level Api (ie. new Playables Api) might be the way to go. Code only and then let the community iterate on that and then Unity can adopt whatever system people gravitate to. If I had more free time I would love to play around with SolarianZ/UnityVisualPlayable: Playable integration for Unity Visual Scripting. (github.com) from @SolarianZ as this is a basis of what a animation graph could look like. Although easier abstractions need to be built on top.
