Search Unity

  1. Welcome to the Unity Forums! Please take the time to read our Code of Conduct to familiarize yourself with the forum rules and how to post constructively.
  2. We have updated the language to the Editor Terms based on feedback from our employees and community. Learn more.
    Dismiss Notice

Question Timeline signal frame accuracy fix?

Discussion in 'Timeline' started by Snowdrama, Jun 10, 2022.

  1. Snowdrama

    Snowdrama

    Joined:
    May 10, 2014
    Posts:
    28
    I have created a timeline with a signal that stores a time, and another to send the timeline back to that time.

    I'm using this to loop an animation within the timeline while I wait for player input because this is a dialog.The dialog advances through some character emotes and then settles on an idle while waiting. however the next animation in the sequence plays right after that animation in the sequence, and because occasionally the signal is called a fraction of a second late, the next animation starts and it causes the animation to jitter since it started an animation it shouldn't have, and then goes back to the start like it should.

    Is there something I am supposed to do to make the signal fire immediately? Some way to make sure the signal is processed before moving to the next frame in the timeline? Is there a better way to set the director time that doesn't have it overrun a signal?

    Here's a simple example:
    Code (CSharp):
    1.  
    2. public class GotToTime : MonoBehaviour
    3. {
    4.     public PlayableDirector director;
    5.  
    6.     public double startTime;
    7.  
    8.     //this is called on frame 60 storing the time
    9.     public void StoreStartTime()
    10.     {
    11.         startTime = director.time;
    12.     }
    13.     //this is called on frame 180 which should take the time back to frame 60
    14.     public void ReturnToStartTime()
    15.     {
    16.         director.time = startTime;
    17.     }
    18.  
    19.     //this is the function called on frame 181
    20.     //this should not be called unless the player has pressed a button
    21.     //in which case the game will advance to frame 181
    22.     public void DontCallThis()
    23.     {
    24.         Debug.LogError("DON'T CALL THIS!");
    25.     }
    26. }
    27.  
    and here's an example of the timeline and the signal: upload_2022-6-10_2-48-20.png

    Edit: I've done some extra stuff and referenced these posts and their issues:
    https://forum.unity.com/threads/ani...-object-via-timeline-signal-callback.1293825/
    https://forum.unity.com/threads/tim...-sent-in-playabledirector-manual-mode.711494/

    I recently did a test where I intentionally made my frames take 300ms, and the timeline will happily skip any Time.deltaTime forward and trigger all signals within that 300ms timeline tick.

    For my situation there the main fix is that, assuming that signals that accumulate in a timeline when deltaTime is large always are executed in order that they are in the timeline, if you execute all signals before evaluating tracks you would prevent any stutter because the signal that manipulates the timeline would be executed before the evaluation of the animation track frame with the "wrong" animation

    Some other things I'd love though is:

    1) Add a PlayableDirector.SetTime() function that will internally clear any signals if the time is set to a time in the past, since this signal will have been executed in the "past" relative to the current time of the timeline and ones that happen after this signal should never have been called.

    2) Add a PlayableDirector.SetPlaybackSpeed() that does something similar internally, if this signal sets the playback speed to 0 then the timeline should essentially use PlayableDirector.SetTime() to go exactly to the time of the signal in the timeline, similarly clearing any future signals that would never have happened.

    Though the biggest challenge would be somehow passing the time of the signal instance on the timeline with the signal execution so I get why these things would be complicated, but it would make using signals significantly more intuitive to use.
     
    Last edited: Jun 12, 2022