Is the new system capable of playing back animations as fast as the Animation component?
In all the tests I have done earlier, using the Animator with an AnimatorController is the slowest way in Unity to play back animations. Using the Animator with Playables is a bit faster than that, but Animation is the fastest by far.
any info about the scripting api for this new system?
This is probably the first announcement that has made me consider actually switching to Unity6. A new workflow is so badly needed and even a slight improvement in performance is great. I do have a few questions about all of this that come from multiple angles though.
How useable is the FSM and Blackboard as just general purpose tools? Can they be utilized for things other than animation similar to how we can use them in mechanim?
What are the performance bottlenecks with the new system? Mechanim’s FSM and animation blending are pretty notoriously heavy. But usually that matters less when you have skinned mesh renderers onscreen because they drown out everything else. However, when using the animator for FSM logic or when not using skinned meshes (like when animating sprites) they pretty quickly become the main source of performance issues at scale. Will the new system fix that?
Can we use this new system to animate things in general? Such as moving object transforms, changing object properties, sprite images, perhaps ECS data?
Will this support lods for skeletons? For example, how hard would it be to swap from a full rig to something like a starfish rig without having to use a completely different gameobject and mesh?
As far as performance goes, I’m not super impressed by 1000 of anything these days but I guess it kind of depends on where the bottle necks are. I’ve used mechanim to animate a thousand sprites using a single-core CPU I bought for $90 sometime in 2011. The animator itself was certainly a bottleneck but I’m not sure where it lies with the new system. Is it the mesh deformation and weighted skinning? Okay, more impressive but honestly anything outside the closest 100 you could probably get away with baked animations in a texture anyway. Is it the FSM and blending? In that case this seems like it isn’t any better performance-wise that Mechanim. The skinned mesh renderer? That’s where the current bottleneck in anyway but at least it would be good to know that the animation wouldn’t be what’s holding us back and it could pave the way for the future quite nicely.
If this is mostly just a case of worlflow improvement and performance isn’t the main focus then I’m fine with that too. Mechanim has always been a real beast, especially when you need to generate anything it uses. Overall, I like the sounds of this but I agree with others that it would be nice to have a preview ASAP so that we can actually give feedback based on real-world use cases.
I have a similar question. Are we able to play legacy or simple animation clips without having to faff around with an Animator, states, etc.?
Sometimes all we want is just raw data from a clip at a certain time.
Hello. First of all, I would like to sincerely thank everyone involved in the development of the new animation package - what you are doing truly looks like a new breath of fresh air into the animation process in Unity.
Tell me, please. We are currently starting a new major project, which will take at least several years to develop. The project will create a huge number of animations with the active use of inverse kinematics. Given that the new animation package is expected, as we understand it, at least at the end of this year, we are still using the old animation system with the Animation Rigging package, but in the future we plan to switch to the new animation package as soon as it appears.
Could you recommend something so that in the future we can make the transition from the “old animation system” + Animation Rigging to the new animation system at the lowest cost?
Cant wait to get my hands on it! This is one of the main reasons I will definitely use Unity 6 as the main base Asset creation tool for my future assets
Hi, there won’t be an API to manipulate the state machine asset for the first release. We appreciate your feedback on this and will consider it against our backlog for future development.
Hi, m not sure to understand to issue you are talking about (would love to hear more!), but netcode doesn’t interact in anyway with animation events in the new animation system.
The new system is a fully featured hierarchichal state machine and we have validated that it is faster than the animation component for a high number of characters. With a low number of characters, like mecanim, it may be slower than the Animation component.
In a future release, the new system will also provide an API to play clip from code without going through a state machine asset, which should then compare favorably with Animation components in all situations in terms of performance. We can’t commit to a timeline for this feature yet.
For the first release, the runtime scripting API should be pretty much on par with Mecanim (set parameters, react to animation events…), alongside an API to write custom nodes.
The FSM is itself designed to perform animation tasks, so don’t expect it to be a general Visual Scripting system where you can put gameplay nodes (like manipulating MonoBehaviours or GameObjects for instance).
However, like Mecanim, it’s possible to tie the equivalent of Mecanim’s StateMachineBehaviours to the states of the FSM (and even to subparts of given clip). As a consequence it’s possible to write gameplay behaviours in C# that are triggered by the animation FSM.
The performances depends on a lot of factors : character count, bone count, FSM state/node/clip counts, … as a consequence the bottleneck will likely vary depending on the context. Our goal for the first release of the new animation system is to be at least as fast as Mecanim in all situations, and faster for a high number of characters/bones/clips. Animating 1000 sprites will certainly be faster than Mecanim. Naturally, we will add options to improve performances in more situations in future releases.
Yes absolutely, except ECS data, this will be available in a future release.
We acknowledge this is a valid need and will work towards this over time. We will not provide this in our first package release
Really appreciate all the answers @FrancoisFournel ! I would not be able to provide this much detail into the tech myself!
I’ll just share that the team is working well together and we’re looking towards the future. By the next time I provide a quarterly update we should have some updates to the public roadmap so you can all better understand where we’re headed and in what prioritized order. We look forward to you all being able to provide us with feedback on our planned features and priorities.
Could I get some more details on this one? Does this mean that in the initial release it won’t be possible to do skinned mesh animation with this system in just entity land?
Background to this is that we’re wondering where to go with animation in our project, most important of all character animation. We have a mobile game running on ECS. We’re crazy happy with ECS. But animation obviously is a real pain point.
Right now, our characters are still running on Mecanim in GameObject land. We’d like to get rid of that.
TBH the approach you’re taking isn’t the most attractive one to us. Completely new system again. We’d rather have baking and support for running Mecanim natively on ECS. And then improvements to Mecanim.
We’ve been trying Rukhanka which in a way is exactly what we’re looking for. Animation controllers baked and running entirely on ECS. Pretty good API and feature set, too. Sadly, it’s proven to be too buggy on iOS leading to graphics driver issues on phones. We’ll probably be axing it to stick with the Mecanim fallback for our initial release.
An entirely new animation system running natively on ECS is probably going to bring significant upgrade cost. But if it allows us to run entirely in entity land, probably still worth it.
The initial release is planned as an experimental package so we wouldn’t advise upgrading mid production especially if you’re targeting your own initial release.
That being said, this is all very helpful feedback and pretty aligned with where we want to be eventually. Just not likely to land in our initial release. We really appreciate your patience and feedback!
No specific or target date yet, but once we have one we will certainly share that.
this is just a caveat with the netcode for gameobjects that doesn’t have anything to do with entities, where animation events are used by the netcode (as in, the actual animation events that can call custom scripts you can add in the animation tab), however, I’m very happy to hear this won’t be something in the new animation system when working with netcode for entities. I had to write some jank implementation to get animation events working for me.
Hey Eric if there is a list of people to try the new animation system I’m one of those hungry people looking to battle test! My game is very heavily animation focused and I already use animation rigging a good deal.
I also would like to sign up for any kind of early access to test the new Animation system in my projects =]
I have a feeling that message was a bit premature. Either way I am very passionate about animation systems. So I’ve been evaluating all of them to see how well the Apis hold up. I’m cautiously optimistic about how this graph system will turn out. So I will put it through the paces just like I did with all the other ones on the asset store.
Specifically curious how it handles more advanced workflows like applying IK at different points in the graph. Using physics to modify a pose. How it handles layers and masks. These early api decisions are going to be hard to change once they are set in stone.