DOTS animation 2020.1 update

Could we get a quick note here on how to get animations working again with 2020.1? Specifically the skinning where the bone index offset was removed. Upgrading entities to latest forces animation upgrade also so it’s difficult to just hold back on the animation upgrade. And something is missing skinning breaks. Single character animates fine multiple do not. Guessing a newer version of SRP but would be nice to get a confirmation on what exactly is needed to get things working again.

So this is kind of a comedy of errors. The animation changelog is wrong for starters about having to remove the bone index offset from b9 forward. It’s really tied to the srp upgrade, and for the latest animation that is a requirement and that’s not said at all. No mention of having to add the version define, and DFG is also busted as it breaks with recent collections not having Unsafe. Which I didn’t even notice until using a separate test project due to we have had collections in dev mode forever so we can use a recent Unsafe dll.

1 Like

I don’t get it why the official does not reply to you.

We’ve just released a version of dots animation that is now compatible with entities 0.13, HDRP 9+, com.unity.rendering.hybrid 0.7.0+ and unity 20.1. As you realized, the dots animation package release is not yet synchronized with entities releases. This is something that we want to fix in the future.

Note that dots animation is still in an experimental state and not yet discoverable through package manager… that is unless you had a previous version included in your project. It’s unfortunate since there has been a lot of code churn recently that we did not want to necessarily expose to you in the immediate term. This sort of breakage is regrettable but can happen while these packages are still very much in development.

Otherwise to answer your question yes BoneIndex is now removed. Your shader graph should just use the Linear Blend Skinning node like so:

Or the new compute deformation node:

Make sure to also enable the following scripting defines in your projects for this to work:
ENABLE_HYBRID_RENDERER_V2
ENABLE_COMPUTE_DEFORMATIONS

5 Likes

Thank you so much for your reply, I want to know Does this latest version support URP? I really need the DOTS ANIMATION to support the URP.

And We wish you to update the Dots Animation Sample at the GitHub. Because it’s been too long since the last time update. And that sample was not compatible with the latest dots animation package for a long time. And I want to say it again URP SUPPORT, URP, thank you!!

2 Likes

It’s been 6 months since the samples were updated. Two years ago, back when the Entities package was in the embryonic stage, its samples repo was still updated with each major update on a regular interval. I don’t see why this one cant receive the same treatment.

4 Likes

@OlivierDionne the linear blend skinning node works great on android. I’m exploring to use compute deformation node, which appear to require hybrid v2 as well as compute shaders. Is there an approach to “fallback” to the linear blend skinning node where compute shaders aren’t supported? Sorry if that’s a dumb question, I’m not exactly a shader expert :roll_eyes:

I don’t like this at all. Why is it necessary to even use special nodes to apply skinning? “Legacy” unity way didn’t require shaders having this and yet performed optimally, with both CPU and Compute skinning methods. Such boilerplate is rarely okay. Maybe it’s time to admit that far from everything can be moved to C# in a clean way?

Try animating 1000+ units with animators in non dots Unity. :smile: That’s why there’s extra work, at least for now, until that happens automatically :slight_smile:

And even then it won’t bring playable framerates. In the grand scheme, it will be slightly worse than legacy unity. For a better comparison, try animating <=35 visible units at any time, DOTS will lag behind. Being scalable in the upper strata is a secondary boon. If it doesn’t perform optimally at the baseline, then it’s a drastic problem.

And that’s about animating, not skinning. The skinning performance by itself was already great with compute shaders to begin with and no extra work for shaders was required. Now, besides already having work on compute, you’ll also need to do some in the vertex shaders, and that’s already a waster and a stick in the wheels. That is precisely what I was referring to. Even if those functions would be added later automatically under the shader generator hood or via a macro, it’s still boilerplate. Again, skinning performance was already great and didn’t require anything from the shaders’ side.

It’s like with HRV2 all over again. It uses a giant Compute Buffer to store per-entity and overriden data which the shaders can access, and all the way through it seemed like a hack to get around an issue of not being able to work with SRP Batcher directly, which already is stupidly fast because it rebuilds per-object ConstantBuffers incrementally and binds them with offsets to, again, bring performance without boilerplate (only requirement being that you explicitly define CBuffers in your shaders, but you should already do that in order not to store everything in a global cbuffer).

All of this looks a lot like trying to get around Unity’s limitations of not being able to access C++ stuff in an adequate and performant way and instead do everything in C# and on the GPU side with shaders, regardless if it’s good or not. Makes me all more curious about how they’re gonna do lightmaps in DOTS.

I will never in my life believe that the HRV2 team made the decision of using a giant ComputeBuffer and partially updating it with Compute Shaders because it’s more performant and that it decreases the usage of bandwidth (that “you send only one 3x3 matrix” argument). You never had a problem with that to begin with because you were on the rendering and job threads while the CPU processed the game logic of the next one, but now you need to be in sync and absolutely must finish your work before finishing the frame and you can’t use optimizations that stuff like SRP Batcher use, because you simply can’t do every relatively low-level stuff in C#.

Again, you can’t do everything in C# without direct access. Most of the major C++ - C# abstractions only get in the way and add further overhead.

SkinnedMeshRenderer now has SRP batcher support, and correct support. Ambient light works correctly and all which Hybrid Renderer still isn’t doing right.

And DOTS animation graph is main thread only.

Characters like you might see in fortnite, customized clothing a variety of unique meshes. You won’t be animating 1000 of those in DOTS. Hobby projects where you are just animating a bunch of simple stuff in a scene doing almost nothing else doesn’t count.

I actually just moved our animation back to playables after several months of waiting for things to get better. Playables is actually fairly performant and we took a pretty small main thread hit going back. There is not a large performance difference vs DOTS if you optimize for playables well.

I’m doing all the math for animation in jobs, with the playable graph updates being just setting data with as little logic as possible. That and using the transform job api’s to update transforms. And those two things put playables roughly on par with DOTS performance for our use case of max 200 characters. Even though we have to keep all the bones in the scene (can’t optimize combined meshes) transform changes have seen a ton of optimization the last couple of years, so that’s not really an issue.

Once DOTS animation graph can be updated in jobs it will move the needle back. And if HR works then it all comes together. You would think that is likely in 2021, but I ran of of time to keep placing bets on that.

2 Likes

I would like to hear from the team what the performance expectations for the animation package are in the near term, and what they are expected to be once its considered production ready, whenever that is.

1 Like

I’m also interested in playable graph, but don’t get much from unity manual and ScriptingAPI. Would you like to share more about playable graph, and how to use playable graph to control animations? BTW, what’s the diffrence between playable graph and the DFG (Data Flow Graph)?

The Data Flow Graph is the future of animation in Unity. It is aimed at replacing Playables… eventually.

The Playables API is how the GameObject animation systems works under the hood. It is the low-level, existing animation system in Unity and more flexible than an animator controller. Here is the examples page for how to get started with Playables.

Playables is in maintenance mode (only receiving bug fixes) so it is very stable, but things like the Playable Graph Visualizer are not being updated anymore. If you want a high level way to use Playables, Animancer is a great asset.

I’d also like to add that Unity’s animation tools, Kinematica and Animation Rigging, are built on top of the job system and Playables (Playables allow use of the job system). Personally, I’m going to stay on Playables until one or both of these packages have preview packages leveraging DOTS animation.

2 Likes

That’s make sense. Thank you for sharing, feel like to digging into the Animation world.:wink:

Any plans for Dual Quaternion Skinning?