Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Is there a way to mitigate the PlayableDirector activation time in the player?

Discussion in 'Timeline' started by jlalone, May 1, 2018.

  1. jlalone

    jlalone

    Joined:
    Jan 18, 2018
    Posts:
    8
    In a development IL2CPP release with optimizations build from 2018.1.0b13:
    Activating and playing a PlayableDirector with four tracks takes about 7.5 ms on our main thread in PlayableAsset.Internal_CreatePlayable and makes over 150 managed allocations, plus an additional 1.25 ms setting up animators. Is this expected behavior and are there ways around this? Almost 9 ms makes it nearly impossible to avoid dropping a frame unless we're already under budget and finished the previous frame early.
     
  2. seant_unity

    seant_unity

    Unity Technologies

    Joined:
    Aug 25, 2015
    Posts:
    1,516
    Calling playableDirector.RebuildGraph() earlier (during an Awake call, for example) will let you mitigate the instantiation cost when playing a timeline.
     
  3. jlalone

    jlalone

    Joined:
    Jan 18, 2018
    Posts:
    8
    Being able to move part of the cost helps a little. I still have to jam 7.5 milliseconds (or more, presumably, for more complex timelines?) of initialization into the main thread somewhere during gameplay for each playable director in a scene after that scene loads. I *might* be able to get away with that in places, but most likely I'll have to restrict its use to just the tutorial scene, which loads before entering VR mode, or have all PlayableDirectors preloaded in a startup scene and assign their bindings dynamically, which sounds moderately awful for my level designer.

    RebuildGraph probably can't be called from any of my other threads, or split into multiple calls on separate frames, or performed on the loading thread during scene load?
     
  4. seant_unity

    seant_unity

    Unity Technologies

    Joined:
    Aug 25, 2015
    Posts:
    1,516
    I can't say those suggestions aren't possible, they very could likely work (e.g. RebuildGraph in theory could be thread safe), but I am not aware of any attempts at it.

    The 7.5ms seems high, but without more context I can't really give recommendations. The number of tracks isn't really as telling as the number of clips on the tracks, or the type of clips/tracks used, but unfortunately the playing of a timeline takes the timelines assets and compiles a playableGraph, and allocations are still necessary for that step. RebuildGraph was put in to allow users to choose when to pay that cost. The trade-off for that cost was more efficient playback (where there should be 0 allocations, and multi-thread support for non-scripted tracks).

    If you have more information about the timeline in question that would really help.
     
  5. jlalone

    jlalone

    Joined:
    Jan 18, 2018
    Posts:
    8
    Attached screenshot of timeline I've been testing with. It doesn't have what I would consider very many clips - two animator tracks and an activation track with one clip each, and one animator track with three transform.position keyframes. Calling RebuildGraph off the main thread definitely isn't allowed by Unity right now.
     

    Attached Files:

  6. seant_unity

    seant_unity

    Unity Technologies

    Joined:
    Aug 25, 2015
    Posts:
    1,516
    Thanks for the info, helpful. The cost is very surprising in that case. I will need to investigate that, there is definitely something off.

    I suggest opening a bug so the issue gets properly tracked. We will investigate as soon as possible.
     
  7. jlalone

    jlalone

    Joined:
    Jan 18, 2018
    Posts:
    8
    Done, though as usual getting a stripped down example project ready took me a bit. Case #1033419.
     
  8. seant_unity

    seant_unity

    Unity Technologies

    Joined:
    Aug 25, 2015
    Posts:
    1,516
    Thanks for filing a case. I have been trying to find time to investigate this, and my observations are that only the first timeline to play has this dramatic of a spike.

    Do your tests confirm that observation? If so, rebuilding a small timeline during a boot sequence may be workaround to that spike.

    While the initial playing of a timeline can be made more efficient, the first one played is an order of magnitude slower, which seems to be at least partially rooted in the application seeing both timeline and playable code for the first time.
     
  9. jlalone

    jlalone

    Joined:
    Jan 18, 2018
    Posts:
    8
    Yes, that matches my latest observations.
    Having an empty timeline build on startup helps a little. Adding one of each track and playable to the startup timeline gives an order of magnitude decrease in timeline rebuild time. I haven't tested if that 'resets' if all or some timeline assets get unloaded, but that's probably not important in our project. This workaround should be fine.