About C# Job system

Hi! I am really excited about the upcoming C# Job system. I really love that Unity is headed in this direction (no race condition multitheading is just dream come true.) Excellent job and praise to Joahkim and his team.

Now to my topic, I was wondering if Unity can post a detailed roadmap for implementing support for Unity native components (eg. Animator, Transform, Physics)

I am pretty sure that we could write our own extensions, but having a Unity written codebase that works right out of the box would be great (efficiency, cleaniness and probably well supported). I can't really see anyone not benefiting from this.

I also think that this might just calm the hype and give realistic expectations of the upcoming feature and probably the time needed to be mature enough for production. I have a colleague who thinks this is going to revolutionize the gaming industry and then there are guys who are quite conservative about its effectiveness. Either way, I think it would just do good if we can get a good document of some sort that levels our expectations.

Hope this helps!

 

I think Transform is already done? (Although probably the only one at the moment). It would be awesome to see Rigidbody be prioritized next.

 

How do you pass transforms in a job since NativeArray don't take Transform as a type?

 

Use TransformAccess and TransformAccessArray

https://docs.unity3d.com/2018.1/Documentation/ScriptReference/Jobs.TransformAccess.html
https://docs.unity3d.com/2018.1/Documentation/ScriptReference/Jobs.TransformAccessArray.html

 

thx, array uh... that thing must fly, I used mavmesh just to get around the transform cost

 

I would rather recommend to prioritize mecanim and its CPU overhead or is mecanim already multithreaded?

 

already multithreaded, it pays off above 20 humanoids

 

so Mecanim won't benefit from the Job System, correct?

 

As I understand it, Mecanim now uses Playables API under the hood, and Playables API is already jobified at the C++ level

 

I am trying to lessen the CPU load of mecanim (wanting to achieve 400 units, maybe 8 animation controller variants) without going into baked mesh route. Any ideas? (Pretty much all is optimized per Unity docs, but is looking for other ways to improve)

Is there a way to update mecanim animation less frequently? eg. 10 times per sec depending on the number of spawned mecanim units or number of animators visible....

 

Yes, from the AnimatorController you can get the PlayableGraph, and with the PlayableGraph you can tick the simulation manually

But I think a better option is to just skip Mecanim entirely and do everything directly in Playables

 

Any good examples how to use playables for mecanim style stuff? cant work it out and docs are all over the place

 

Hello!

We're really excited about the C# job system as well, and as we get closer to the release of 2018.1 more plans and roadmaps will begin to appear.

Regarding which other systems are good candidates for being C# job'ified, thank you for your suggestions. It is a little outside the scope of the 2018.1 beta program to cover future features. But we are listening and will obviously try to prioritise areas that are highly needed first.

 

A good intro point is SimpleAnimation, which is a Unity-made project that replicates the behaviour of the old Animation component with Playables.

 

Thanks!

 

800+lines of code for simple animation? No thanks

 

800 lines for that seems like a lot for that (it probably reads your Tarrot) but it's 800 lines that you don't have to write

 

It's actually kinda the future of Unity as well, instead of bloating out the core engine, Unity can offer some great extra functionality with package manager. I think @Rene-Damm mentioned it regarding input, and some other mentions have been had. I'm personally extremely excited that Unity will help do some boilerplate for me

 

To return to the topic, the current Mecanim system can only handle around 300 units with all the unity optimizations. The CPU bottleneck is quite severe from that point on. I hope they really work on mecanim performance. handling vertex animated units through GPU and achieving 10000+ units is great, but IMHO that is just for very few few situations. Most of the times, games will be running Mecanim.

Mecanim is a well made, powerful tool, so I think Unity should really focus on improving its performance - or are they just letting it scale with the multi core era? I guess if everyone had 16 core CPUs, the problem will naturally fade away

 

I think if they can just ECSify the PlayablesAPI, I'll be very happy with that. For me personally, Mecanim is starting to show its age and has too many limitations in terms of workflow

 

Maybe, but I think Mecanim is a good base to handle robust scenarios and works better. I am just not satisfied about its performance. I might even have to resort to vertex baked solution soon...which really sucks.

BTW, do skinnedMeshRenderers support instancing?

 

There's this project here on github: https://github.com/Unity-Technologies/Animation-Instancing

I haven't looked at it a whole lot, but it does seem to rely on Graphics.DrawMeshInstanced and a vertex cache of all frames of the animation for rendering. So it's not an automatic solution that "just works". I'm not sure such a magical solution could exist either, because skinnedMesh instancing does require some form of "baking" of all the things you'll need for your specific game

 

Thanks for the link, I will check it out. Hope this turns out to be useful.

 

I thought that too being a hardcore mecanim user, but since playing with playables, timeline and extending them, I have found they serve more cases than mecanim ever could in a robust manner.

 

Ah yeah? Got any example that'll knock my socks off?

 

unfortunately its more of the design side that makes it enjoyable. The actual code is like 400x bigger, and I have not found a way around that bloat. That said, using playables with timeline and the playables graph makes it possible to make those "bigger" pieces of code do a lot within a visual editor.

I am at work at the moment but at the weekend I will try and post back here with some of my playables that I am using.

Definately look at simpleanimation, its horrible to read but when you actually use it in a project with the playable graph, it becomes amazing. So much fine control over blending of animations its fantastic. Very easy to sync up these blends with scripts and other transitions due to the playable api. But its taken me like 6-7 months to get to this stage where I see the use, youll see in the past I was raging on these forums about how hard and strange playables are XD

 

I am more concerned about its performance rather than its simplicity or control. Can I expect better performance with Playables in general? My aim is to have 500+ agents solid at 60FPS.

 

Mecanim is a layer built on top of Playables API now. So in theory, that would mean that there's more potential for performance with using Playables API directly than with Mecanim.

Also, another interesting thing for animation performance is the AnimationStream API. This will be great for all kinds of procedural animation/IK/etc because you won't have to rely on modifying Transforms for these things anymore. You'll be able to modify the animation stream directly instead. Some details at the end of this post: https://blogs.unity3d.com/2017/08/02/unity-2017-1-feature-spotlight-playable-api/

 

If you want performance, that animation instancing that @PhilSA gave you is the bomb. 2000 agents at 60 fps, mecanim coughs 2 fps on a good day.

 

I mean if you want true performance with ECS, use https://github.com/chengkehan/GPUSkinning

GPU skinning and doing the animations via a shader is the most performant way I can think of for lots of agents