I know in 2018, Unity released their experimental Animation C# Jobs with the Playables API,
but I was wondering if the general Playables API (and my custom Playables) runs on the main thread, or takes advantage of the C# Job System?
I know in 2018, Unity released their experimental Animation C# Jobs with the Playables API,
but I was wondering if the general Playables API (and my custom Playables) runs on the main thread, or takes advantage of the C# Job System?
Ah, just found this post with some cool insight.
It seems like if you’re NOT manually calling Evaluate(…) on the graph, it does use multithreading to its advantage where needed (it uses different parts of the PlayerLoop internally).
I guess this answers my question for the most part!
You can get concurrent execution of more than one animator if you put them all inside of one graph instance. It sucks, but it works.
Hahaha, it sucks as in – it’s a pain to setup and keep working properly, but it’s possible?
Yea, sucks in the sense that you have to have a global graph instance and then jam every single animator into it, but yea it works and I’ve had no issues on iOS, macOS, or win64. I’m not sure how expensive it is to add/remove root nodes from a graph, so if you are doing that alot you will want to profile and see if it’s a problem.
But… then don’t they share all the triggers and variables too?
Sounds like a nightmare.
Well, using low-level playables API on an animator means no Mecanim. I also don’t use animation events that Unity automatically fires (I null them out and do my own), so there could be some weirdness there.