Unity Animation state

Unity animation samples repo doesn't seem to be maintained. A lot of unanswered issues and last commit is for 6-8 months ago while Unity Animation packages has released a few versions in last 2-3 months.

I like to use Unity Animations for humanoid animations in a hobby project.
What is the status of this package?
My requirements are animation blending, layers and masks.

I did not find any documentation on how to use it on manual page.
Can someone provide some information and workflows?

 

S k i n n e d M e s h e s w h e n

 

That's the same question that I have been always asked, But they did not answer me, I feel very sad. Because It's been too long for not updating.

 

This answer about Unity.Animation status is from a while a go: 2020 Roadmap Q&A - Core Engine & Creator Tools

From my understanding, the package is in a very experimental state. They are probably going to mostly be internally developing it with very infrequent public samples until 2021.

 

If animation is experimental then they don't even have a label that fits Hybrid Renderer.

The main thing about this package is how low level it is. And it's not going to add value for a lot of games at this point. It's a very situational package in terms of can it bring value to the table vs mecanim or even legacy animation.

The only real potential value add at this point is for animating a lot of characters. It is cheaper there but also not by as much as you might expect. The actual animation barely wins out over legacy in main thread usage. But since it works with regular meshes you get a good bump from the instancing. But if you aren't animating enough things to really matter then using DOTS animation is more of an exercise in masochism.

 

So one can assume this workflow will improve* as with everything else that is consistently and constantly changing with regards to the ECS?

*IMHO DOTS is getting rather confusing now with all the interfaces, labels, authoring, and so forth.

 

I just got a small update on the state of the animation package: https://forum.unity.com/threads/multiple-changehandlers-on-a-localizedstring.950756/#post-6222594

 

Well it at least gives you the option to multithread it, which is not the case with mecanim I think(?) Also not having to make a confusing hybrid GameObject/ECS thing just for supporting animation is a plus

I don't understand people using things like UnityAnimation or NetCode or HybridRenderer in real projects at this point. As I understand it, they are clearly announced as just early proofs of concepts that should not be used yet, and will change a lot in the future. They're just a way for Unity to show us that something is coming and this is the work that has been done so far

One thing I would say about Unity.Animation, though, is that I'm a fan of its Playables-style API for creating animation graphs. A node editor will be a necessary tool to add in the future for sure, but even today I often end up sticking to Playables API rather than mecanim Animators, just because complex graphs are easier to work with in code format than in node format (and code gives you more power for procedurally creating graphs)

 

You have succeeded to obtains more information than me on official Q&A thread, congrats !

 

Labels don't mean much you really have to take each package on it's own value. Like animation has been more stable then hybrid renderer by far, seen fewer refactors, etc.. We are using it in a yet to be released game I don't see it as a risk. It's use of HR is a risk, but we can always go back to making it use DrawMeshInstanced which we had at one point. Our basic layers/blending code hasn't changed since we implemented it when DOTS animation first hit. The core api's have not really seen much churn. Around the edges yes, like how they parent renderers they can't seem to make up their mind.

Mecanim does use the job system, it's issue there is it doesn't give them much time to run before it force completes them. It's a shame because if they fixed that mecanim would perform so much better.

DOTS animation graph updates have to happen on the main thread and it's a significant chunk of work.

The main win for us with DOTS animation isn't it's animation performance it's being able to use regular meshes which simplifies our character clothing customization greatly. Regular meshes also enable SRP batcher or using any of the instancing api's if needed. Skinned meshes have a number of constraints that can be painful.

 

Is it possible to use DOTS animation without backing entities (eg just a MeshRenderer GameObject)? That would be much more flexible, especially given that URP is still behind builtin in terms of features and performance (making HRv2 a no-go for me)

 

You can and it's conceptually straight forward because remember it's just a regular mesh. What api you render it with doesn't really matter. What matters is the skinning in the shader. Before we moved to HDRP we had it working in legacy rendering.

So figure out the shader skinning using HDRP as a guide, the actual skinning logic is pretty simple. Then sort out the best way to disable HR rendering them and how to get the skinning data from animation to pass to your shader. Starting from zero your biggest task is just learning the codebases in this area. I could get DrawMeshInstanced or meshrenderer rendering working in a few hours I'm sure, but I know the code involved fairly well by now.

 

Mecanim is multithreaded. It uses Playables internally.

Although it takes a bit of work to create a good hybrid workflow / interface, it actually works really well once you have one up and running. I'm able to get a significant speed up implementing IK solving in ECS and writing the results back to animator's rig bone transforms.

Yeah I get the same impression with the Netcode and Animation packages. Netcode seems to be in a weird state where it seems really immature, but it still shows up as a preview package (without adding it manually to the manifest).

 

However, invoking the Playables API is bound to the main thread, and multiple graphs cannot be evaluated concurrently. I'm not sure if DOTS Animation is the same way, but if it's just another job, it should be possible to run multiple evaluations in parallel.

 

Graph updates in DOTS animation are main thread only. Graph rendering is concurrent. Graph updates can be run in their own thread but have to be synchronized at some point, we hacked it to do that ourselves at one point and then backed out those changed until things stabilize a bit more.