Search Unity

  1. Get all the Unite Berlin 2018 news on the blog.
    Dismiss Notice
  2. Unity 2018.2 has arrived! Read about it here.
    Dismiss Notice
  3. We're looking for your feedback on the platforms you use and how you use them. Let us know!
    Dismiss Notice
  4. The Unity Pro & Visual Studio Professional Bundle gives you the tools you need to develop faster & collaborate more efficiently. Learn more.
    Dismiss Notice
  5. Improve your Unity skills with a certified instructor in a private, interactive classroom. Learn more.
    Dismiss Notice
  6. ARCore is out of developer preview! Read about it here.
    Dismiss Notice
  7. Magic Leap’s Lumin SDK Technical Preview for Unity lets you get started creating content for Magic Leap One™. Find more information on our blog!
    Dismiss Notice
  8. Want to see the most recent patch releases? Take a peek at the patch release page.
    Dismiss Notice

Optimizing animation jobs

Discussion in 'Animation' started by snacktime, Jul 25, 2018.

  1. snacktime

    snacktime

    Joined:
    Apr 15, 2013
    Posts:
    1,601
    So PreLateUpdate.DirectorUpdateAnimationEnd/DirectorUpdateAnimationBegin are the main cpu hogs I'm tackling now. And it looks like most of the cpu time is jobs being completed early, forcing the work back on the main thread. Which makes me think messing with the player loop here could possibly solve this.

    But I'm sure the current ordering is done in consideration of dependencies I have no clue about. Anyone, maybe someone from Unity, can give some advice on where to stick stuff to maximize job time for animations?
     
  2. snacktime

    snacktime

    Joined:
    Apr 15, 2013
    Posts:
    1,601
    Also, I'm not using root motion, but in the timeline Animator.ProcessRootMotion is by far the largest chunk of cpu time for animations. I'm assuming it's just a bad labeling thing, hate to think it's actually processing something it doesn't need to.
     
  3. Mecanim-Dev

    Mecanim-Dev

    Unity Technologies

    Joined:
    Nov 26, 2012
    Posts:
    1,575
    Right, we just fixed it in trunk
    it now called Animators.ProcessGraphJob which evaluated the whole graph

    we did also rename
    Animators.IKJob to Animators.IKAndTwistBoneJob
    Animators.DirtySceneObjects to Animators.WriteProperties

    Animator.WriteAnimatedValues to Animator.WriteTransforms

    and we did add the following one

    Animator.EvaluateTwistBone
    Animator.PrepareAnimationEvents
     
    hippocoder likes this.
  4. Mecanim-Dev

    Mecanim-Dev

    Unity Technologies

    Joined:
    Nov 26, 2012
    Posts:
    1,575
    This is not really what is happening.

    We do kick jobs from the main thread which is then free to continue to process other thing but at some point the main thread hit a sync point and has to wait for animation job to complete so rather than sitting idle the main thread start to process animation jobs too.
     
    hippocoder likes this.
  5. snacktime

    snacktime

    Joined:
    Apr 15, 2013
    Posts:
    1,601
    That's what I meant by being completed, just different wording for the same thing. It's the end result that matters, which is the main thread ends up doing a significant amount of work.

    My question was actually how to get around that sync point. I tried moving stuff around via the player loop to no avail. From your response I gather you aren't sure what that sync point even is off the top of your head. What it looks like is that it's likely synchronizing for stuff that isn't always required. That the job dependencies are such that say when it gets to a transform sync, it say's ok we need to sync root motion, but the dependencies are not granular enough to not do that when no root motion is running (that's just a hypothetical I have no clue about actual dependencies).
     
  6. snacktime

    snacktime

    Joined:
    Apr 15, 2013
    Posts:
    1,601
    Actually the sync point whatever it is, is specific to animation jobs or has a dependency on them at least. Otherwise I'd see the main thread waiting somewhere without animations running, which it doesn't.
     
  7. snacktime

    snacktime

    Joined:
    Apr 15, 2013
    Posts:
    1,601
    Another way to look at it is that whatever that sync point is, without animations it's tiny. A few fractions of a ms worth of work is being done on the main thread. But it's forcing several orders of magnitude more animation work to be done on the main thread. Characterizing that as using idle cpu time is well, kind of wrong.
     
  8. Mecanim-Dev

    Mecanim-Dev

    Unity Technologies

    Joined:
    Nov 26, 2012
    Posts:
    1,575
    In fact thoses sync point are from the animation update.

    there is some step that need to be done on the main thread like everything that call a c# function: firing animation events, calling state machine behaviour, calling OnAnimatorMove.

    And since in a script anything can happen, like an animation events fired by animator A can disable any other animator. we can't have a job running on animator B while other animator are firing events so we need to wait for all jobs to finish before we can start thoses step.

    Now one could argue that we could move those step at another time in the animation update loop but the thing is that would be a behaviour change and would break old project.

    One option that we have is to write a completly new update loop and let user choose if they want the new update loop or the old one. We did try it and it give good result but we don't have any resources to finish it right now.
     
  9. snacktime

    snacktime

    Joined:
    Apr 15, 2013
    Posts:
    1,601
    Ya that makes sense. Unfortunate but it's good to know what's really going on there thanks for the update.