Animator.ProcessRootMotion even when not using root motion.

Hello,

We are using 2017.4.LTS version of Unity, our characters use Generic animator type and no root motion at all, the bool is set as false. Still tho, the profiler shows Animator.ProcessRootMotion with around 0.1ms per animator update - which, as many times we have 50+ character on screen significantly affect our FPS.

Is it normal behaviour or we could evade it anyhow?

 

Bump, can anyone confirm this is normal behaviour or how to evade that?

 

Bumping!

 

yes this is expected, in 2018 this profiler tag has been renamed to Animators.ProcessGraphJob.

Animator.ProcessRootMotion was a bad name for this step.

this step is mandatory as it does evaluate the whole animation graph

 

Okay, thank you

 

Hi, resurrecting this thread as in 2020.3 I can still observe AnimationScriptPlayable.ProcessRootMotion in the profiler (despite ApplyRootMotion disabled), directly under Animator.ProcessGraph (itself included in Animators.ProcessGraphJob) . What's going on with this?

 

Unity still runs the ProcessRootMotion function of IAnimationJobs, even if there is nothing to be done. None of the Animation Jobs in the AnimationRigging package actually use RootMotion, but Unity still schedules jobs for them!

This means that if you have a lot of very lightweight rigs / AnimationScriptPlayables, Unity spends half of the animation time scheduling jobs that literally do nothing.



See here, where it schedules the ProcessRootMotion jobs for MultiParentConstraintJob:


... for which the definition is empty:

Code (CSharp):

1. /// <summary>
2.         /// Defines what to do when processing the root motion.
3.         /// </summary>
4.         /// <param name="stream">The animation stream to work on.</param>
5.         public void ProcessRootMotion(AnimationStream stream) { }
6.  

 

@Mecanim-Dev Is there any way to force these root motion jobs to be skipped? This is happening even with Animator.applyRootMotion set to false. Unity 2020.3.17f1

 

You can see here how it's spending half of the animation time, just on running these empty jobs:

 

Why not test this with 2021.3 LTS or even 2022?

 

Just not worth the time, unless it seems like something that would be fixed. This seems like an intentional architecture decision, not a bug. Plus, we're stuck on 2020.3 for the time being.

We solved this by writing our own animation logic in a custom job, and skipping the Animation Rigging package entirely. That made it 10-20x faster, haha.

 

Sounds awesome! Even though of sharing the solution via asset store for example?

 

Here's the code we ended up with. Added some comments at the top, too.
https://gist.github.com/Kleptine/04719a52cd53917f82a7e05cf8bd9046

 

Just noticed this on 2022.2, it's a huge performance drain on useless processing if you're not utilizing any root motion. I can't just modify the animation package, or whatever is scheduling it, to get rid of this right? Makes me reconsider whether to use AnimationRigging if that's the cause