Animation C# jobs in 2018.2a5

Timeline uses the Playable API indeed, but the Playable API is not made just for Timeline. The Playable API is a low-level API that allows to create your own data-flow graph. This data-flow can be for animation, sound, video, scripts, ...
So you can use the Playable API and do whatever feature/tool without ever having to touch the Timeline.

Playable API being already quite low-level, we haven't planned to go even lower. Maybe in the future, who knows? Maybe we'd need more abstraction, but for the moment, ECS and Playable API are two low-level (lowest?) Unity APIs.

I do think you can already do very low-level work just using the Playable API (which is multi-threaded for the animations, even with an AnimationScriptPlayable). But if you want to go even lower, you could do your own animation system with your own format, using ECS

Thanks man!
We already have some plans about how to redo some parts, but new techs (like ECS) frequently change these plans
We'll keep in touch!

 

That's right! -- I do remember that now! -- I haven't messed much with the PlayablesAPI yet aside from Timeline, so it seemed like a really odd thing to tie the two together with low-level Animation stuff too. Thinking on it though, since the PlayablesAPI and "streaming Animation data" deal with time-based dataflow at a pretty low-level, it makes a lot more sense now.

That's quite exciting! -- I really need to get some time to invest in the possibilities of the new animation system! Sadly, it's difficult to skim (sparse) documentation sometimes, and it almost always requires heavy experimentation (which takes a lot of time to even just get a grasp on what's going on!) but it definitely sounds like it's worth getting to know! -- If ECS is really that powerful that I could make my own very low-level animation systems, that means it can't come fast enough!



Speaking of low-level animation stuff -- do we have access to the skinnedmesh bone names and starting orientations etc. directly from the model's file (and at runtime) just yet? -- I find this to be very limiting when trying to mask out things (such as parts of a skeleton to ignore while transforming other parts of the model's skeleton manually).

Sounds really awesome! -- I feel like we totally need better animation tools and I would seriously love to contribute wherever I am able to! Things like general use-case scenarios and UX for animation are things I've dreamed about since I was a kid.

 

Can we use Job system and ECS to make Editor development? like Editor Mode Animation system play around animation data in the Editor Mode. We can define our own data structure and own animation logic so on.I want run my system not only in Play Mode but also in Editor Mode.

Thanks.

 

I guess it's possible, but I don't know much about ECS since I haven't played with it yet. And the Animation C# Jobs uses the C# Jobs System, but this system is yet another low-level feature that is beyond the scope of this thread

 

Can we also get an example for twistbone/adjustmentbone support and additive/corrective blendshape?

 

Good proposal, I created two issues for that:
https://github.com/Unity-Technologies/animation-jobs-samples/issues/3
https://github.com/Unity-Technologies/animation-jobs-samples/issues/4

 

The sample is really nice but may I be greedy and ask for something with dynamics? Like a pony-tail or hair.
I am guessing things like powered ragdolls are out of the question.
Lastly in the foot IK for mecanim is it possible to specify what part of the foot we want for contact? Eg toe vs heel vs ball

 

A sample with physics is in the pipeline right now.
Maybe we could do a CCD example as well.

I encourage you to create new issues in the repo if you have ideas, we'll triage them as they come

 

I encourage you even more to fork the project, try to do the sample yourself and propose a PR (if you have the time). We would gladly review it!

 

i think what he mean is jiggle bone

 

This and more

 

@RomainFailliot any news about active ragdoll and ragdoll in/out transition? i remember someone mention that an example for that is in the progress?
Edit : oh wait sorry that was you , any news?

 

Do you mean the blending between an animation and rigidbody that was mentioned earlier? I'm curious if I could use it to make swords clashing look good and also maybe ease up on the actual animation work that would go into that part. Right now it's kinda awkward having to convert the direction of the hit into a 2d space to be used in a 2d blend in the Animator for different reactionary animations.

On another note I've wanted to dive into procedural animation since I watched

but back then I figured that it wasn't really possible in Unity without writing an entire custom system myself. I was so excited to read about this on the 2018.2 blog update. Would you guys consider a sample on basic walking/running animation made out of a couple keyframes/poses like David Rosen showed on the presentation starting from around the 5:20 mark?

 

This was already possible since unity 3.
I think any implementation of this sort would have to be custom code as it is heavily dependent on the game you are making and needs a lot of trial and error iteration.
It is simply key frame animation with a custom interpolator

 

Here's a talk from Unite Berlin that uses Animation Jobs for IK, if you prefer this in video form:

 

Follow up questions from a while ago!

The big problem with DSP is that it's timescale independent. This means that setting Time.timeScale to 0 to pause the game doesn't do anything, the graph still plays like normal. This is unlike the Animator, which does respect the timescale.

I think DirectorUpdateMode.GameTime is a more sensible default value for playable graphs - yes, people mixing together audio and animations will have to figure out that they have to change the time mode, but that's probably better than that everyone else needs to figure out that they have to change the time mode.

DSP clock is a special case for fixing a special case issue, no?

 

Can anyone explain the differences between a TransformStreamHandle and a TransformSceneHandle?

Mostly wondering...
- performance difference of setting position/rotation of each of these
- what makes a particular transform able to be "resolved" as a TransformStreamHandle? Does it need to be part of the Avatar?
- is it possible to access transforms created at runtime via a TransformStreamHandle?

 

Another question:

What is the correct approach if we want to use raycasting to position our IK targets since we cannot do a raycast from inside our IAnimationJob? Seems like the targets would have to be positioned separately and would always be one frame behind the animation when the IAnimationJob executes

 

@RomainFailliot is this thread still monitored or is there a better place to direct Animation Job questions?

 

@TheValar
Hi, yes the thread is still monitored, it's summer time so some of us are still on vacation .

The biggest difference is the fact that stream handle are processed by the animation stream which mean that they are blended if you have a mixer in your graph or modified by any animation jobs in the graph.

When you read or write into a TransformSceneHandle you're directly reading or writing a value into the transform.
When you read or write into a TransformStreamHandle you're manipulate the animation stream data.

Performance wise TransformSceneHandle cost some extra memory, also since you are directly manipulating a transform from a thread we need to sync the transform so if many jobs access the same transform it could slow down the system but that should be an edge case.

yes to be able to resolve a TransformStreamHandle, the transform must be part of the avatar definition.

yes, but it has to be part of the avatar. So either you create an avatar definition with all you're runtime props already define upfront or you generate a new avatar.

You can easily create a generic avatar with this call at runtime.

Code (CSharp):

1. var avatar = AvatarBuilder.BuildGenericAvatar(go, "");

Generating a humanoid avatar is possible too but more complicated.

 

Is exposing the automatic humanoid avatar generation on your roadmap?

 

yes it on the road map but I have no idea when we will do it, surely not short term.

 

i found a performance problem in animation-jobs-samples project. i create a lot of 500 prefab by DefaultMale_Generic , i use c# job with play anim is very low efficiency.. but i do animator anim not with c# job, is very highly active。 you can see the profiler photo... why the multi-threaded animation job is so low efficiency? please tell me ? is my way use error ?

 

That's normal unfortunately. It's why we have to go back to old methods of animating if we want even a few dozen skinned meshes doing anything.

 

I'm sorry, I don't understand your case very well. Could you send a project please?

 

I would challenge anyone at Unity to show how to animate 500 characters with anything resembling decent performance. Maybe there is some esoteric trick that none of us have found?

500 low poly characters optimized gameobjects no root motion chews up an average of 12ms per frame on my system. Out of 16 that you need to hit 60fps. That basically gives you enough to render and hardly anything left over.

The really frustrating thing is most of that time is taken up in root motion/ik calculations, which I don't even have enabled.

It's just simply flat broken for anything even approaching any kind of scale.

 

@snacktime To my knowledge, I don't know any engine that is able to render 500 fully animated characters out-of-the-box, without using some tricks (like GPU instancing).

In @amao's test, most of the frame is spent in DirectorUpdateAnimationEnd, which doesn't seem to be linked with the rendering. But I can't understand what was actually tested in the scene, it seems that the test was between 500 characters with an animation and 500 characters without an animation. If that's the case it seems logical; playing an animation costs more than not playing anything at all.

 

Hi @snacktime,

I'm sorry to heard that you can't achieve the performance that you would like and would be happy to investigate with you what are your culprit but first using the animation c# jobs thread for this is not the right place.

If you want to start a new thread to discuss about this and post information about your project like:
What hardware are you targeting?
What is your animation cpu budget?
Which animation feature you would like to use?

Also some animation profiler marker are badly named, they do not give a clear idea of what is really happening.
I've just pushed a change yesterday to rename some of those

by example
Animators.ProcessRootMotionJob is now called Animators.ProcessGraphJob
Animators.IKJob is now called Animators.IKAndTwistBoneJob

 

One, mecanim takes double the cpu to do the same core basic animation and cross fade/blending that legacy does. Same results, double the cpu usage. So either mecanim is implemented badly (which I doubt), or it's doing a bunch of unnecessary work for the simple case, which is what the data points to being the case. This should at a minimum be configurable somewhere.

Two, you run a lot of the logic in jobs, but for some reason complete it too quickly making the main thread wait, which is the same end result as just running on the main thread to start with. I'm guessing because of other job dependencies. This seems fixable, I asked about it on another thread with no reply.

The point isn't what some other engine can do. It's what it looks like Unity should be able to do right now if it fixed what looks to be things that are fairly straight forward to fix.

FYI that gpu skinning is basically broken I'm actually working on fixing it now. No bone weight blending in cross fade, abstractions what exist of them mostly wrong for doing it correctly (and for adding layer blending). So that's what I'm actually using, but I really shouldn't have to IMO.

 

I didn't really want to drag this thread off topic (but nobody was listening to on topic threads I started). But the relevance here is that if you want simple animations, legacy is a far better choice in many cases. Unless you just don't care about the extra cpu usage with no value attached to it.

 

If Unity could make up their minds about wheter the legacy component is deprecated or not, that'd also be great.

 

In animation-jobs-samples project, i want to know if the multithreading animation is efficiency and workable ? is can be used by a lot of player to play animation. maybe some ways to solve the problem, but not perfect like animation instance... i wish multithreading can do more things to solve some efficiency problem, like animation, load assetbunndle, Instantiate gameobject ...

 

In the Austin Tech Presentation - the one that SpellSouls team showed a battle with 100,000 agents using the jobs system - they animated all the agents and the game got around 50 fps.
Would this animation jobs system help us achieve a result near this? If not are you planning to do so?

 

SpellSouls are using a custom system for their animation, in fact i don't think they use animation at all. All the animation data are baked into the texture if i'm not mistaken.

 

Exactly!
But I guess the jobs system couldn't reach its maximum potential without a relatively easy solution for animating the large number of entities you can control with jobs.

 

Honestly isn't unity main problem when dealing with a lot amount of animated character are the Skin Mesh Renderer?
i believe unity able to handle thousand of bones transformation especially with c# job, but still bottleneck at the skinned renderer? is there any info regarding skinned mesh renderer improvement @RomainFailliot ? sorry if this is are bit out of topic.

 

Hello all!

We made a blog post @Mecanim-Dev and I, and it's been published a few minutes ago: https://blogs.unity3d.com/2018/08/27/animation-c-jobs/

 

Thanks a lot, I will be using these examples extensively and throwing out my old monobehaviour based ones. Thanks again Romain and team.

 

@Reanimate_L I didn't really delve into the skinned mesh renderer in Unity but I downloaded the GPU skinning asset (it uses a mesh renderer to animate high number of characters), and also the Austin Tech Demo and found out that they wrote there own skinnedmeshrenderer. So I guess yeah you are right.

Thanks @RomainFailliot and the team! Will have much to learn!

 

Hi guys!
I started with a simple test of mixing two animations in a job as described at https://github.com/Unity-Technologies/animation-jobs-samples in the MixerJob.cs script, on 400 characters. Then I took the same setup and replaced the Job with an Animator and a Blend Tree, doing exactly the same thing.
The Job scene runs at 25 fps and the Animator scene runs at 50 fps. This came as a surprise since I was expecting the Job to be much more stripped out and, on inspecting the Profiler, I saw that the Animator is using its own IAnimatorJob interface behind the scenes, scheduling jobs in the same way, but way more efficiently.
So my question is, is it worth replacing the Animator with a custom Job system if there is nothing that I want to do apart from simple transitions and blending on lots of characters? If it is, then is there someone who can point me in the right direction?

 

If you want to animate lots of characters use GPU Skinning. There is a free asset in store by that name. However, it doesn't work with pure ecs.

 

The test is still animator vs code, probably to see how it performs.

 

Hi, the goal of the job system is not to replace what is already working but rather extend the system to achieve new thing that wasn't possible before.

Here some technical details that will help you understand what is going on under the hood and all the operation that we need to do to call managed code from a c++ worker thread.

An animator doesn't know what a animation job is, the only thing that an animator know is how to evaluate a playable graph, the animator walk the graph and evaluate each playable.

With animation jobs we did introduced a new playable call AnimationScriptPlayable which acts as a proxy between playable and animation jobs. Each AnimationScriptPlayable has a payload which containt all the managed job data, so when the animator walk throught an AnimationScriptPlayable, the proxy load the managed job data from main memory, invoke the c# methods and then finally store back the managed job data to main memory. As your job data growth this copy operation will take more time.

Of course performance is something really important for us and we will continue to improve it.
Using the burst compiler is also an option to improve performance because animation jobs system is based on c# jobs system.
https://forum.unity.com/threads/burst-for-standalone-players.539820/

 

OMG! the person who deleted my comment clearly did not understand my post. It was relevant to animation jobs.

I was simply trying to figure out how to use the mixer to blend between any two clips
but start with both clips at unique positions

at the moment AnimationStream.deltaTime is readonly

Code (CSharp):

1.     public void ProcessAnimation(AnimationStream stream)
2.     {
3.         var streamA = stream.GetInputStream(0);
4.         var streamB = stream.GetInputStream(1);
5.  
6.         //This will not work because it is read only
7.         streamA.deltaTime = 0.2f;
8.         streamB.deltaTime = 0.12f;
9.      
10.         var numHandles = handles.Length;
11.         for (var i = 0; i < numHandles; ++i)
12.         {
13.             var handle = handles[i];
14.  
15.             var posA = handle.GetLocalPosition(streamA);
16.             var posB = handle.GetLocalPosition(streamB);
17.             handle.SetLocalPosition(stream, Vector3.Lerp(posA, posB, weight * boneWeights[i]));
18.  
19.             var rotA = handle.GetLocalRotation(streamA);
20.             var rotB = handle.GetLocalRotation(streamB);
21.             handle.SetLocalRotation(stream, Quaternion.Slerp(rotA, rotB, weight * boneWeights[i]));
22.         }
23.     }

Is it also possible to mirror a stream?

 

Perhaps a post like you just made was necessary

 

The deltaTime come from the engine, thus you cannot modify it.

if animator.updateMode is set as AnimatorUpdateMode.Normal then the deltaTime will be a Time.deltaTime
if animator.updateMode is set as AnimatorUpdateMode.AnimatePhysics then the deltaTime will be a Time.fixedDeltaTime.

From what I understand, what you would like to do is sample clips in the graph at a specific time. You can do this but not from an animation jobs.
Topological modifications on the graph, connection weights change, or time changes need to be done from a monobehaviour Update methods or from PlayableBehaviour.PrepareFrame before the graph evaluation.
https://docs.unity3d.com/ScriptReference/Playables.PlayableBehaviour.PrepareFrame.html

So since you need to control the time of your playable, first you need to Pause them in the graph
https://docs.unity3d.com/ScriptReference/Playables.PlayableExtensions.Pause.html
so pause all your AnimationClipPlayable under your mixer
and then set the time for those playables with
https://docs.unity3d.com/ScriptReference/Playables.PlayableExtensions.SetTime.html

 

Seems a bit involved
Before I try this. Is it possible to have multiple characters run on 1 instance of a playable or must they all create a new playable unique to themselves?

For some reason, I imagined it would be the case that there was only one instance of each unique graph

 

Hello!

@Mecanim-Dev gave a good description of what's going on under the hood. Since you're not the only one wondering about that, we'll add a comment in MixerJob.cs explaining that it is slower than our dedicated mixer playable, AnimationMixerPlayable, and that it is here only for the purpose of learning how you would do a simple mixer.

I'm sure it's less hard than you think
The AnimationJob doesn't control the time of the playable, that's why AnimationStream.deltaTime is readonly. If you want to change the time and how it is elapsed on animation clips, you should use the Playable node. In all the Playable nodes you can change the speed, with Playable.SetSpeed, and the time, with Playable.SetTime.

The TLDR is: if you want to change the start time of an animation clip, you should use Playable.SetTime right when you're connecting the AnimationClipPlayable in your graph.

The PlayableGraph and its Playable nodes are already instances dedicated to a character, so you can't instantiate them any more. But if you want to instantiate as many PlayableGraphs based on a pattern, you should take a look at PlayableAsset.

 

It looks really nice~

 

I am revealing my noobness here but I don't think you support mirroring. Please tell me you do