Search Unity

New in 2019.1 - Timeline Signals

Discussion in 'Timeline' started by julienb, Dec 6, 2018.

  1. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    814
    This is where I'm at on (most -- but not all) Unity tools since Mecanim.

    It seems like Unity's tool development process isn't much different than Nintendo's sometimes.

    That is:

    Develop in a vacuum, (with all external input being empty data points on someone's personal Excel spreadsheet), expect naysayers to eventually come around at some theoretical point in the future (our late 2000's track-record is spotless -- we noe what u want), put important features in a "maybe" category for potential release of version 2.0, (because we got no funds/budget/time available to deliver what you want -- what we wanted to deliver was always our first priority.)

    This is fine for certain cases -- but not all tools can be approached in this "visionary" (read: aloof / artsy) way.
    Great for investors (at first) -- but terrible for business (in the end.)
    Why?
    Timeline signals, for example, definitely have a "kinda cool" use-case as they are -- but the limited scope of their use (after waiting so long for them) turns out to be quite disappointing to some.

    As users, some of us tend to feel a little betrayed a little too often by Unity thanks to this approach.

    Like Nintendo, Unity seems to focus on chasing down "new" approaches and ideas, leading them to neglecting their simpler "bread-and-butter" empathy and technical knowhow that originally won their fans over to begin with.
     
    Last edited: Mar 12, 2019
    tbriley likes this.
  2. cirocontinisio

    cirocontinisio

    Unity Technologies

    Joined:
    Jun 20, 2016
    Posts:
    33
    This is what Clips are for. Markers are inherently "duration-less" (and in any software).
     
  3. tbriley

    tbriley

    Joined:
    Sep 10, 2013
    Posts:
    111
    not true.

    https://support.apple.com/kb/PH13186?locale=en_US

    or

    https://www.ableton.com/en/manual/arrangement-view/

    see section 6.5, the arrangement loop ^^^

    maybe just semantics to you, but when i am trying to take the tool seriously on a project i regularly bump into limitations where i can feel this sort of attitude in the software. it's also the general tone of this thread, users trying to communicate why something doesn't feel good and someone from unity essentially saying "you're holding it wrong".

    and it's beside the point -> fine, let "signals" be duration-less. but when a user gives feedback my advice to you is to try to understand the full context of what they're attempting to communicate:

    "i can totally understand why they were designed this way but it doesn't take long to come across use cases where it makes sense for certain marker types to have this"

    basic playback + arrangement controls (make it all duration-less if you feel that strongly about the design). signals with some embedded data. data types (and signal design) that play nice with DOTS / ECS. a way to make new clip types that doesn't still basically require a wizard to generate the code for you (or better yet, just include a stronger set of built-in clip types). i want the tool to feel like it's gone beyond its initial release / demo state and is in-line with unity's future. and to be clear, i'm not expecting something as fully-fledged as a standalone sequencer like ableton or logic. i also truly, truly understand that like any business unity has limited resources and everything you do is tradeoffs and every user has different expectations and you're never going to please everyone. more "wow" ;)
     
    awesomedata likes this.
  4. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    814
    Exactly. Well-put.

    This is the reason why even users who _really_ want to support Unity, can't find themselves saying nice things about many of their tools -- The attitude users receive upon pointing out "problems" with major features (like where are true, flexible, Timeline Events?) is very clear:

    "If it ain't working for anyone but me and my team -- that means it's not broken."

    :'(
     
    Last edited: Mar 14, 2019
  5. Xarbrough

    Xarbrough

    Joined:
    Dec 11, 2014
    Posts:
    505
    Is there any chance Signals are going to be backported to 2018.3 or would somehow work as an external package? We've started development on a project locked to 2018.3, but we would love to use Signals.
     
  6. sebastienlh

    sebastienlh

    Unity Technologies

    Joined:
    Sep 22, 2017
    Posts:
    23
    @Xarbrough Sadly, we will not be backporting Signals to 2018.3. As a general rule, features are never backported, only bug fixes.
     
    Xarbrough likes this.
  7. Kiupe

    Kiupe

    Joined:
    Feb 1, 2013
    Posts:
    524
    Hi,

    I was wondering why a receiver should be in the Timeline ? I mean, I understand why it has to be in the Timeline regarding how it works. But if the signal asset would have handle/contain the event (unity event) it could have be different. The signal assets could expose a Unity events, signal receiver could subscribe to that event and an emitter could tell a signal asset that it has to fire its event. That way it would have been possible to notify an arbitrary of receiver in the scene without having to explicitly add them to a timeline track.

    Does that make sense ?
     
  8. ricmorales22

    ricmorales22

    Joined:
    Nov 29, 2015
    Posts:
    10
    Hello, really excited about Signals and Markers. Is it possible to make markers emit notifications in edit mode? Preferably while scrubbing the timeline? :D

    I'm thinking I'd need to create a custom track and put the logic in there somehow... any help appreciated!
     
    createtheimaginable likes this.
  9. julienb

    julienb

    Unity Technologies

    Joined:
    Sep 9, 2016
    Posts:
    130
    You can invoke a reaction in edit mode by changing the dropdown value in the Unity Event UI:
    editorAndRuntime.png

    Signal Emitters do not emit when scrubbing though.
     
  10. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    814
    You know -- after @cirocontinisio's latest (too quick) run-through of the Timeline Signals & Markers, I am finally intrigued about the system you guys built. He said _just_ enough to make me wonder about it, but still not quite enough to actually show us _how_ you wanted us to use them.
    I feel like you guys really should put out a detailed video or two showing what kinds of things you guys suggest we do with the markers/signals systems. They definitely seem novel, but they subvert people's expectations a little _too_ much for us to know exactly what kinds of projects or workflows they were intended for.

    We expected a straightforward "Events" system, kinda like the Animation Events -- but on Timeline. We got something way different (but perhaps, a bit more robust -- we don't know -- we just need some better insights on what this system brings that Animation Events on a Timeline couldn't.)


    I hope you guys consider shedding some light on this stuff so that those of us who couldn't follow your reasoning can finally be on-board with you guys. You've got a cool-looking setup, and you've obviously put in a lot of work, but I'm sure I'm not alone in feeling like I'm still not quite there with you... :(
     
    createtheimaginable likes this.
  11. andybak

    andybak

    Joined:
    Jan 14, 2017
    Posts:
    162
    Or an illustrated blog post. Please no more videos - I can skim an article 10x faster than I can listen to someone drone on through a damn video.

    (Sorry - had to get that off my chest. Totally baffled by the reliance on videos for stuff that would be much more accessible and informative in other formats)

    Anyway - @awesomedata makes a very eloquent and valid point. Lots of people here just haven't clicked with the new way of doing things, I'm personally still baffled what the advantage in making a single text string into an external asset file are despite a couple of attempts to explain it.

    The complexity/flexibility trade-off just seems out of whack here but that's probably a lack of insight on my part so please illuminate us.
     
    Last edited: Apr 19, 2019
  12. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    814
    I agree about the ad-hoc / scatterbrained nature of some of these videos.

    Honestly, having a random person try to hit on a small set of talking points might be easier on the production side, but it can be a pain for users to later have to scrub through to reference any "feature-relevant" information we need about otherwise undocumented features. The blog posts are hit-or-miss on quality too. Yes, a well-documented and illustrated post, _can_ be better than a video for reference, but the (often heavily-outdated) information never disappears. So as a source of learning _and_ reference, it's better to have both. New information is often more accessible and easier to produce in an ad-hoc video format for quick turnaround, but information not mentioned in one format may be mentioned or clarified in the other. Videos for quick learning and spreading of info, and (frequently-updated) blog posts for reference.


    Whether through video _or_ illustrated text, there somehow still tends to be loads of very important (and very relevant) information "missing in translation" to end-users -- case in point: the current direction of this topic.



    That's really true -- We want to have faith in you guys, but with little information or insight on where you're coming from (or what you intended for us to do), plus the fact that we've been burned many times in the past (and have waited years to be heard!) -- it's really hard to just go on faith alone that you guys have really thought this through from our perspective. I see that there is a deeper idea now behind this new system (thanks to @cirocontinisio's talk), so I've personally regained some confidence, but I've yet to really gain the insight that you guys are expecting me to have on how you intended it to be used. By simply telling me "it's powerful", it doesn't really help me see _why_ subverting my expectations was better.
     
    cirocontinisio likes this.
  13. 5argon

    5argon

    Joined:
    Jun 10, 2013
    Posts:
    1,265
    I actually agree that (literally/semantically) markers should have no duration. What you want in Ableton's "loop marker" sense is 2 markers that are constrained to each other. Maybe this is a more useful and concrete proposal for UT to consider :

    - The left and right marker triggers different kind of notification, already in definition of a marker. In Ableton's loop marker sense the left marker do nothing but the right one sends back the playable graph time to the time of left marker. The left one may send a notification to begin record mode for the punch in feature.
    - The first one's `time` must be equal to or lower than the second. You want this supported first class by having the Timeline GUI constrain this. So it is not possible to drag the right one past the left and have a "flipped" pair of markers, ruining the fixed function of left and right markers. Or if the flip is possible, left and right markers must automatically switch places.
    - If the left and right marker is at the exact same time, you want the GUI to show this reasonably. It is still possible to grab either marker to pull them apart, currently not possible as overlapping markers are displayed with + sign.

    I would name it "linked marker" of sorts, and it would be certainly useful if Unity made it. (
    class LinkedMarker<L,R> where L : Marker, R : Marker
    ?)

    I have one more related request too.

    It would be useful if a clip playable asset could also be INotification that notifies on entering the left side and again on exiting the right side. (Set INotification as the clip itself that implements INotification just like when marker is a notification, but maybe make use of currently null `context` variable to tell if it was from the left or right side)

    Use case for this is like the "dialogue clip" from this article https://blogs.unity3d.com/2018/04/05/creative-scripting-for-timeline/. Here (https://github.com/UnityTechnologie...mTimelineTracks/Dialogue/DialogueBehaviour.cs) when notification API wasn't available it simply embed the stop logic in the clip's processing.

    Now that the notification API is available I would like to realize this logic using a notification and only with clip, so the notification fires properly on entering the left side and I could implement a stop there. I could certainly implement this with overlapping markers positioned at the left edge of the clip, but it would be ugly and make editing them in the Timeline GUI less ideal. Not to mention I have to carefully copy the marker-and-clip together everywhere.

    It is also possible for me to make my clip's playable behaviour to do things like TimeNotificationBehaviour and just call PushNotification on the playable's output in addition to my own dialogue logic, but I think that's not ideal either.

    Receivers are not in the timeline asset.
    • Timeline has tracks.
    • Any track could contain markers. MarkerTrack could only contain markers and not clips.
    • When play head goes over a marker, it check the track's binding (any kind of track, marker or not). If that binding is a component, it finds that component's owning game object. If that track is a special "Marker" top track, the binding is assumed to be PlayableDirector component running the timeline asset's created playable graph, then it continue to find that director's owning game object.
    • That found game object will finally broadcast a notification to all of its component that's with INotificationReceiver. If a SignalReceiver (is an INotificationReceiver) is on this game object, it will be notified. The SignalReceiver is not in the timeline asset but a MonoBehaviour on a game object, that should be sitting near PlayableDirector if you wish to use the top Marker track or near your binded component if the signal markers are coming from other tracks.

    SignalAsset could not expose UnityEvent as it is an asset being, stored in asset folder without knowledge of scenes. UnityEvent needs to connect to something in the scene to invoke, so it needs to be on some kind of MonoBehaviour's exposed field. SignalReceiver fits this requirement, so SignalAsset's task is just for the SignalReceiver to check which specific signal in the timeline was sent as a notification. (TimelineAsset too is an asset being and has no knowledge of the scene at design time until PlayableDirector create a graph out of it. The timeline uses SignalAsset as a bridge so SignalReceiver could do something with the scene)
     
    Last edited: Apr 30, 2019
    awesomedata and tbriley like this.
  14. Kiupe

    Kiupe

    Joined:
    Feb 1, 2013
    Posts:
    524
    @5argon thanks for the answer, but I'm still wondering/thinking that they could have an approach more similar to Ryan Ripple
    .
     
  15. sacb0y

    sacb0y

    Joined:
    May 9, 2016
    Posts:
    178
    This is a really odd thing to me, like, i under stand more fundamental deeper features like the bone per vertext thing (desperately needed) or something like raytracing. But whats the point of stuff like package manager where things that could be highly beneficial like this are left only to newer unstable versions. And I have to wait a whole year just to gain a stable version cause i just wanted a few features and risk my whole project breaking as a result. I have to debate if i want to deal with a whole new thing in a new unity version just cause 4 bones per vertext (as i said understandable but still) is unberable or I want to be able to more effectively use the timeline (main issue).

    Like is Unity built to grow with peoples projects, or is it built for the perpetual new projects that pop up or just for people to tinker with? I don't need SRP and all that other fancy technology stuff, but basic functionality for major features like timeline would make me feel a lot more confident in it. Cause otherwise it seems more like an inconvenience to use these unity features rather than buy an asset that is backwards compatible or have to program something myself. Maybe i'll just use it next game in 2-3 years.

    But above all, why is 2018.3 mentioned in the GDC video if this is not the case?
    upload_2019-5-2_5-31-30.png
     
  16. 5argon

    5argon

    Joined:
    Jun 10, 2013
    Posts:
    1,265
    The signal feature which is a part of Timeline (package) is depending on Timeline's Marker feature, which in turn depends on notification feature in UnityEngine.Playables added in 2019.1. Playables is not yet a package, it is implemented natively. I guess that's the reason why signals couldn't go back in version as a package.
     
  17. Lost-in-the-Garden

    Lost-in-the-Garden

    Joined:
    Nov 18, 2015
    Posts:
    167
    Do you think it would be possible in the future out of the box, or easily implemented by myself that there is also a SignalEmitter as a Component?
    I sometimes would need a Signal to be fired in the timeline or if some User Input happens before that through a game component.

    Thanks,
    Matthias
     
  18. Bill-Sansky

    Bill-Sansky

    Joined:
    Oct 2, 2016
    Posts:
    60
    I ran into an issue with Signals: seems that they don't get called if you manually modify the time of the playable director and call Evaluate:

    Code (CSharp):
    1.            
    2. Director.time +=Time.deltaTime;
    3. Director.Evaluate();        
    4.  
    This won't call the signals.
    Is there any method to call on the top to call the signals, or is that a bug?
     
  19. ZeBraNS

    ZeBraNS

    Joined:
    Feb 21, 2015
    Posts:
    23
    Hi,
    is it possible to use Signals to start playing UI element animation?
    I have tried a couple of ways but no luck.

    Thanks
     
  20. cirocontinisio

    cirocontinisio

    Unity Technologies

    Joined:
    Jun 20, 2016
    Posts:
    33
    Sorry for the long delayed answer.
    Fair enough, I didn't know other software had the concept of markers with a duration. To me it sounds new, that's what I think clips are for (they offer a lot of control and events, on start, an update loop, on end, etc.). I personally don't see a big use in replicating the same functionality in Unity's Markers to get something very similar to the Clips, and then having people confused on when to use one or the other. But I'm not in the Timeline team so this is just a very personal opinion.

    For the rest, you have some very good suggestions and criticism in your last paragraph. I'll ping the Timeline team to keep it in mind, if they haven't seen it already.

    That video is mine. The slide refers to the fact other smaller improvements are also present in 18.3, but I do say in the video that Markers and Signals are available as of 19.1.

    More than having a Component that fires a Signal notification pretending it's a marker, I'd do it a different way: have 1) a Component (or another bit of code) and 2) the SignalEmitter (on the Timeline) that can call the same function, which is in a third location. That way you centralise the functionality somewhere else.

    Sorry it was quick, that was a 20 minutes talk at GDC and I had to cram a lot of stuff in it. I'm glad it was useful though!

    We hear your feedback on the videos. In case you missed it, Julien posted a blog post: https://blogs.unity3d.com/2019/05/21/how-to-use-timeline-signals/ with more details.
     
    Last edited: Jun 20, 2019
    tbriley likes this.
  21. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    814
    The reason why your 20 minute talk was so much better than the blog post (imo) was because you gave a holistic overview of the reasoning and possible use-cases behind the signals workflow -- and how they were intended to be applied in workflows.

    For this, you did a great job!

    This tiny part about workflow is all too easily missed by Unity as a whole everytime a new feature or tool is released. It took YEARS for Mecanim users to finally have enough trial-and-error behind them to finally suss it (and its blackbox API) out (and it's still not entirely understood what's going on behind the scenes). Mecanim's wildly-specific workflow for animation was proposed, but there were huge problems with it in practice once users began to finally understand it -- but, by that time, Unity's development efforts had long-since shifted elsewhere because Unity assumed people loved it due to their silence. However, I assure you that this silence was mostly because many people couldn't make heads-or-tails of what they would have to do in order to fit this into their workflows -- and this was Unity's answer to animation at the time (and currently, the only solution, for the moment) -- including for stuff like procedural animation and facial animation for most people. Nothing broader than state-change was considered in its design, not even logic -- nor was the poor usability of having to manually create trigger variables in the editor window (without lots of backend code) to do the inevitable logic alongside overly-complicated scripts.
    Things have gotten better since with Mecanim, but the fundamental workflow is still very flawed in practice.
    It seems like someone comes up willy-nilly with the suggested workflow, then everyone just nods, so it gets greenlit, then it fails to ever get mentioned to users what the originally-intended workflow was, since it has probably mutated greatly by the end of a feature's development and release.

    I wonder if this is what happened to Timeline's signals/markers workflow?


    It really seems like Unity in general expects everyone to think: "Wow! That's really cool! -- Let's use it!"

    While the (real) reaction is typically: "Wow! That's really cool! -- How many days (or weeks!) is it realistically going to take me to get my head around their specific workflow and apply this (again, very specific) workflow to my own workflows? -- I need a better workflow, but is this new concept/workflow really that much better? They didn't tell me how it could apply to other workflows. How can I know it's even worth the time for me to learn? -- I've got so many other tools/skills I need to learn, and documentation is sparse. I'll probably just learn it later."


    There is usually no more than one suggested workflow, and no "here are ways how you could generally use this (as-is) to do various things like..." types of examples (usually step-by-step is good -- but from multiple usage scenarios/perspectives). That arrow-key input video in the blog about Timeline signals really didn't help much in this. It was oddly-specific, really fast, and didn't tell me anything about how I might use signals for something else -- something more complex.


    TL;DR:

    Your holistic overview and general suggestions were a lot more useful, @cirocontinisio -- I could learn the steps to do the integration later.
    For now, I mainly need to be shown the possibilities -- particularly how the system could be used.
    Being shown different usage scenarios is the only real way I can evaluate whether or not learning the new system would better-serve my workflow.
    This is what can spark people's imagination to use it in their own projects/workflows -- and get you better (more timely) feedback.
     
    Last edited: Jun 21, 2019
    Bill-Sansky likes this.
  22. andybak

    andybak

    Joined:
    Jan 14, 2017
    Posts:
    162
    awesomedata likes this.
  23. Steven-Kodani

    Steven-Kodani

    Joined:
    May 6, 2013
    Posts:
    1
    I'm curious about this also - If I set the PlayableDirector timeUpdateMode to DirectorUpdateMode.Manual and call Evaluate() myself, my signals don't seem to trigger.
     
  24. sebastienlh

    sebastienlh

    Unity Technologies

    Joined:
    Sep 22, 2017
    Posts:
    23
    @Bill-Sansky & @Steven-Kodani What you are seeing is the expected behaviour. We are explicitly not triggering notifications on a call to Evaluate(). The Timeline must be playing to trigger any form of notification.
     
  25. Bill-Sansky

    Bill-Sansky

    Joined:
    Oct 2, 2016
    Posts:
    60
    This is problematic because it means it is impossible to use signals when manually playing the timeline: could we have some API access in order to evaluate the signals, or anything close to that?

    When you say that the timeline must be playing, the problem is that if I move the time manually, it is in fact "playing" so that seems like an inconsistent behaviour to me, especially because PlayableDirector has the "manual" update mode exposed.
     
  26. sebastienlh

    sebastienlh

    Unity Technologies

    Joined:
    Sep 22, 2017
    Posts:
    23
    @Bill-Sansky Sadly, we can't know on our end how you seek in your Timeline and to avoid unwanted behaviour, we make no assumptions about what happens between your calls to Evaluate(). However, you have all the tools necessary to call the Signals yourself in your update implementation.

    You can get all the markers on a specific track using track.GetMarkers() and filter them using their time property. With that information, you can get the signal receiver and call receiver.OnNotify(null, myMarker, null).

    Hope that helps.
     
  27. Bill-Sansky

    Bill-Sansky

    Joined:
    Oct 2, 2016
    Posts:
    60
    I see that makes sense.
    It would be great to have a way to perform this independently of tracks.
    A method like EvaluateFromTo(float startTime, float endTime) would be awesome for instance :)
    I will take a look at the track method you mentioned, thanks!
     
  28. Kichang-Kim

    Kichang-Kim

    Joined:
    Oct 19, 2010
    Posts:
    312
    @sebastienlh Hi, I found that playing timeline in timeline editor does not triggers custom marker, but signals are triggerred. Is this intended behaviour? Playing scene correctly triggers both marker and signals. I used Unity 2019.2.0f1.

    Edit: Implementing INotificationOptionProvider makes my custom marker is triggerred in editor mode.
     
    Last edited: Aug 7, 2019
    julienb likes this.