About C# Job system

Unity Engine
1

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!

1 Like
2

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

3

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

4

Use TransformAccess and TransformAccessArray

5

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

6

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

7

already multithreaded, it pays off above 20 humanoids

8

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

9

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

10

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…

11

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

1 Like
12

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

13

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.

1 Like
14

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

2 Likes
15

Thanks!

16

800+lines of code for simple animation? No thanks :stuck_out_tongue:

17

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 :wink:

18

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 :slight_smile:

3 Likes
19

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 :smile:

20

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

3 Likes