Search Unity

  1. Unity 2018.3 is now released.
    Dismiss Notice
  2. The Unity Pro & Visual Studio Professional Bundle gives you the tools you need to develop faster & collaborate more efficiently. Learn more.
    Dismiss Notice
  3. We've updated our Terms of Service. Please read our blog post from Unity CTO and Co-Founder Joachim Ante here
    Dismiss Notice
  4. Want to provide direct feedback to the Unity team? Join the Unity Advisory Panel.
    Dismiss Notice
  5. Improve your Unity skills with a certified instructor in a private, interactive classroom. Watch the overview now.
    Dismiss Notice

Timeline Wrap mode set to none but when timeline force stop by code, model hold still instead t pose

Discussion in 'Timeline' started by Suika, Mar 15, 2018.

  1. Suika

    Suika

    Joined:
    Nov 19, 2013
    Posts:
    33
    In play mode.

    Timeline Wrap mode set to "none" but when timeline force stop by code, model hold still instead t pose (Like Wrap Mode "Hold").

    Is that a bug? If not, how to set model back to t pose in play mode when timeline stop by code and wrap set to None?

    Thx.
     
    morita-esw likes this.
  2. seant_unity

    seant_unity

    Unity Technologies

    Joined:
    Aug 25, 2015
    Posts:
    644
    It's technically by design, as the animator doesn't update unless told to by a timeline or controller, although there are cases where you would want to revert the pose/state of an animated object. I don't believe there is a 'default pose' stored on the object in Playmode to revert to.

    There are a couple things you could try
    • Animate a copy of your object and hide the original.
    • Make an animation clip of your default state, and use a controller or playables (or simple animation) to reset after the timeline is done.
     
  3. taylank

    taylank

    Joined:
    Nov 3, 2012
    Posts:
    53
    @seant_unity
    May I recommend a proper inspector option to revert for PlayableDirector? Without a revert option, the reusability of timeline assets at runtime becomes questionable because each one of them leaves the scene in a different state, and thus affects the playing of the next one. With due respect, the options you recommend are unnecessary workflow friction to compensate for something that should be a regular feature.