Closed vallcrist closed 1 year ago
The approach described in that thread should work, but as I mentioned there my initial testing didn't find any significant difference (which is unexpected so I intend to look at it again for the next version of Animancer).
I see. We're trying some different approaches and overall we found a significant performance boost by letting the jobs run naturally without calling evaluate. Even if the total time spent animating ends up the same, freeing up the main thread for running things that can't or aren't able to run in jobs atm brought us some good improvements.
Would be awesome to have a way to either separate the time advancing from the actual animation job or to at least queue the manual time advancement from other parts on the code
Hi. :)
We're working on a multiplayer game and we're approaching animations with a FSM that manually triggers the state for animancer. In order to have a bit more control we decided to go with the Manual update mode for the animancer playable, calling Evaluate manually with the correct time interval.
However, this seems to force all the animator updates to happen on the main thread, and even calling Animators.Update multiple times (ie.: 80 animators triggering 160 calls on the profiler).
Some quick testing showed me that yes, calling evaluate manually is affecting the performance a bit in our case. We could really use the offloading to the worker threads as our game currently needs all the help it can get offloading the main thread, so is there any way we could advance the animancer graph by a custom amount, but let the usual flow trigger the updates and offload it to the worker threads?
I saw a similar thread where the user wanted to customize the update rate and hit something similar, but it wasn't clear if there was any result from it: https://github.com/KybernetikGames/animancer/issues/241