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

New in 2019.1 - Timeline Signals

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

  1. julienb

    julienb

    Unity Technologies

    Joined:
    Sep 9, 2016
    Posts:
    112
    Since Timeline released in 2017.1, there has been a lot of requests for events. With good reason; it was something that was sorely missing. Some people implemented events through clips (by the way, thanks to everyone who offered their custom event implementation to the community), even if, in this use case, clips had their shortcomings.

    Well, the Timeline team is proud to offer you an early Christmas present: signals are now available in 2019.1.0a11!

    A new item has appeared: markers!

    A marker is new item that can be added to a timeline. It is used to represent a point in time.
    Markers can be added and manipulated on a timeline the same way as clips; selection, copy-paste, edit modes etc. should work. A marker also has a specialization, just like clips (Animation Clip, Activation Clip, Control Clip, etc.). In 2019.1, Timeline offers its first built-in marker: Signal Emitter marker.

    What are signal emitters?

    Signal emitters are used to trigger a change in state of the scene when the timeline passes a given point in time. We used the word signal instead of event because it supported the idea of "broadcast" while avoiding the confusion with the already existing Unity Event and Animation Event.

    Where can I add a Signal Emitter?

    A Signal Emitter can be added on the timeline and on tracks (with some restrictions).

    - On the timeline: This is a new concept for this release. Signals can be added on the timeline itself. No tracks are needed in this case.
    - On a track: Signals can also be added to any track, as long as the track accepts a binding. We’ve also introduced a new type of track, a Signal Track. This track accepts only signals but no clips.

    Keep in mind that where you place a signal emitter will define how this signal is received. More on that later.

    How does it work?

    In order to properly set up signals on a timeline, you need three pieces: a Signal Asset, a Signal Emitter and a Signal Receiver.

    graph.png
    • Signal Asset: This asset is the link between an emitter and a receiver. Basically, the Signal Asset acts as an identifier.
    • Signal Emitter: A Signal Emitter is placed on the Timeline. It contains a reference to a Signal Asset. When played, if the current time is greater than the emitter’s time, the emitter is triggered; it will send its Signal Asset to a Signal Receiver.
    • Signal Receiver: The Signal Receiver is a component that has a list of reactions, each of those reactions are bound to a Signal Asset. When a receiver is notified that a signal has been triggered, it will invoke the reaction bound to the corresponding Signal Asset.
    The main idea that guided our design was to make the piece that sends the signals (the emitter) as independent as possible from the piece that listens and reacts to signals (the receiver). This design adds a lot of flexibility and is very powerful. Let’s see in details how all those pieces work together.

    The Signal Emitter

    1. Create a timeline. Then, click on the pin button near the edit modes button.

    2. The Timeline Marker area is now displayed. Right-click in the area under the time ruler and choose Add Signal Emitter.
    3. In the Signal Emitter inspector, click on Create Signal… to create a new Signal Asset to your project.

    4. Still in the Signal Emitter inspector, click on Add Signal Receiver. The inspector should look like this:

    The Add Signal Receiver button did the following:
    • It added a new Signal Receiver component to the bound object. If the Signal Emitter is on a track, the component will be added to the track’s bound object. If the Signal Emitter is on the Timeline (like I did in my example) then the Gameobject which owns PlayableDirector will have a new Signal Receiver component.
    • It added a new reaction bound to the Signal Asset I just created.
    I can then use the Unity Event UI to define what should be invoked when the Signal Emitter is triggered.

    The important part is that the Signal Emitter inspector first shows you properties related to the Signal Emitter. It also displays, for your convenience, the Signal Receiver that will receive the signals.


    The Retroactive property, when enabled, will trigger the signal if the timeline begins playing after the signal’s time.
    The Emit Once property, when enabled, will trigger the signal only once when the timeline loops.

    The Signal Receiver

    Let’s take a look at the Signal Receiver component. Click on the Gameobject that owns the Signal Receiver.


    It shows you nearly exactly what we saw previously; the Explosion signal is bound to an empty UnityEvent.


    Let’s say we want to add a new Signal Asset. We can do it right here. Click the Add Reaction button. A new reaction was added, bound to nothing. Click on the dropdown and choose Create Signal...


    Here is my result after I created a new asset:


    The Signal Receiver is now setup to invoke reactions when it receivers the Explosion and Load Scene signals.

    If I go back to the Timeline, then I can add a Signal Emitter that either sends the Explosion or the Load Scene signals. I can also easily switch between the two.





    So in a nutshell, how do I setup my first signal?

    You need a grand total of 4 clicks:
    1. Right-click on a track which supports signals, then choose Add Signal Emitter
    2. In the Inspector window, click on Create Signal Asset, choose a file name and hit Enter (one less click :p)
    3. Still in the Inspector, click the Create Reaction button.
    That’s it! In the Unity Event UI, you can setup what is necessary for the reaction associated with the signal you just created.

    Can I create my own markers/signals?

    Yes, you can. See this thread: https://forum.unity.com/threads/new-in-2019-marker-customization.594712/

    I’m finished! It was a long wait, but we hope it was worth it. Enjoy!
     
    Last edited: Dec 7, 2018
    5argon, Griz, Intense_Gamer94 and 5 others like this.
  2. u7ku

    u7ku

    Joined:
    Jul 17, 2018
    Posts:
    2
    Sweet!!! I was worried this was dropped from the roadmap.
     
  3. julienb

    julienb

    Unity Technologies

    Joined:
    Sep 9, 2016
    Posts:
    112
    You can also check this video that will give you an idea of what is possible with signals:
     
    ledbetterman, osss, Vectrex and 2 others like this.
  4. AndrewKaninchen

    AndrewKaninchen

    Joined:
    Oct 30, 2016
    Posts:
    53
    Having signals be empty objects seems counter-intuitive to me. Shouldn't there be, by default, a way for signals to have information embedded in them?

    Say I wanted to have a Timeline with multiple explosions, to go in line with your example. But say I also wanted all of those explosions to be slightly different. Would I need to create, for every explosion, a different signal?

    And then, worst of all, whenever I created any other Timeline, would all those signals be shown in their dropdowns, even if they have nothing to do with those signals at all? This last part seems to be easily solved, at least in the abstract, by embedding Timeline and Signal objects in their Scenes instead of their own separate assets. That way everything that matters could be referenced easily and you wouldn't fill you dropdowns with an endless number of useless things.

    But really, even having to create multiple signals for basically the same thing in the same Timeline bothers me conceptually. I'd very much rather have the marker itself be responsible for the parameters used by the Emitter, or whatever other abstraction which would allow me not to need creating a million Signals for very simple things.

    Markers, Signals, Emitters and Receivers being 4 separate things looks like a lot of overkill to me and kind of seems to break the purpose of having everything that happens neatly packed in a timeline. I think I understand the wish to have decoupling from Scene references into Assets (it's something that comes a lot into my mind), but it'd be much better to have it be an option, not a necessity.
     
    Last edited: Dec 7, 2018
  5. Vectrex

    Vectrex

    Joined:
    Oct 31, 2009
    Posts:
    203
    Great job. I like the decoupling of actions.
    Andrew: If you wanted that you could just make a custom script and control the randomness from normal variables etc.
    I presume, since it's UnityEvent the timeline can also pass variables into function calls, which would allow it to control complex functions without having to hack in programming like functionality into timeline.
     
    ledbetterman likes this.
  6. AndrewKaninchen

    AndrewKaninchen

    Joined:
    Oct 30, 2016
    Posts:
    53
    The idea is not randomness, it's actually quite the opposite.

    upload_2018-12-7_13-6-45.png

    Basically, I don't want to have to create a different Signal Asset for every single set of slightly different function calls. It would pollute the signal dropdown stupidly fast.
     
  7. Vectrex

    Vectrex

    Joined:
    Oct 31, 2009
    Posts:
    203
    Ok, I assumed it worked like the Animation events, where you could call any function and EACH call could have unique parameter values passed through. It seems like this doesn't do that.

    Also these functions work except the multi-parameter ones. Which I think should be supported. The old events only took one and it was quite a hassle.

    Code (CSharp):
    1.  
    2.     public void DoThings()
    3.     {
    4.         print("DOthings");
    5.     }
    6.     public void DoThings2(int num)
    7.     {
    8.         print("DOthings "+num);
    9.     }
    10.     public void DoThings3(string str)
    11.     {
    12.         print("DOthings "+str);
    13.     }
    14.     public void DoThingsGO(GameObject go)
    15.     {
    16.         print("DOthings "+go.name);
    17.     }
    18.     public void DoThings4(int i, string s)
    19.     {
    20.         print("DOthings");
    21.     }
    22.     public void DoThings5(int i, string s, GameObject go)
    23.     {
    24.         print("DOthings");
    25.     }
    26.  
    It appears that each keyframe shares the parameter values with the Signal file? I was wondering why he created two signals for each foot, when I assumed it'd be just adjusting the parameter values passed to the function.

    Trying to set the 3 keyframes to different values failed for me.
    upload_2018-12-8_4-13-46.png
     
  8. JakubSmaga

    JakubSmaga

    Joined:
    Aug 5, 2015
    Posts:
    401
    Shouldn't the Timeline .playable asset hold all of the signals instead of us having to create and save each signal asset inside the Assets folder? Because for me it looks like the whole signals system just isn't how it should be done.
     
  9. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    24,177
    Thanks a lot for the pressie - I think we might have to start making moves toward timeline integration now.
     
  10. julienb

    julienb

    Unity Technologies

    Joined:
    Sep 9, 2016
    Posts:
    112
    ledbetterman and Lars-Steenhoff like this.
  11. AndrewKaninchen

    AndrewKaninchen

    Joined:
    Oct 30, 2016
    Posts:
    53
    The example project in this thread is exactly what I was talking about! Shouldn't something more like that be offered as default behaviour alongside the signal stuff? I can see it's mostly quite simple stuff to implement by yourself if you know what you're doing, but not having this as a built-in and recommended way of doing it only serves to preemptively destroy any possible consistency between projects.
     
  12. andybak

    andybak

    Joined:
    Jan 14, 2017
    Posts:
    41
    At first glance it does seem a tiny bit over-engineered... A bit 'enterprisey'...
     
  13. Kiupe

    Kiupe

    Joined:
    Feb 1, 2013
    Posts:
    465
    Sounds interesting.

    Can an SignalAsset be extended in order to add it properties that can be retrieved by a SignalListener ?

    Does that mean that with the current workflow only one SignalReceiver can be "bind" to a SignalAsset ?

    There were a lot of videos and hype about ScriptableObject to handle properties and events - it would have been cool to have a SignalAsset to be like this - meaning be able to trigger when the SignalEmitter is "consumed". SignalReceiver could simply registered to the SignalAsset. It would allow to have more than one SignalReceiver "listening" to a same SignalAsset.

    Thanks
     
  14. starikcetin

    starikcetin

    Joined:
    Dec 7, 2017
    Posts:
    181
    Yay Adobe Flash!
     
  15. andybak

    andybak

    Joined:
    Jan 14, 2017
    Posts:
    41
    Lol. I must admit to sometimes missing timeline based style of development. It became unfashionable in the same way VB6 click and drag dev did - for some good reasons - but you can't beat it for speed and convenience and accessibility.
     
  16. julienb

    julienb

    Unity Technologies

    Joined:
    Sep 9, 2016
    Posts:
    112
    Thanks for the precise and thoughtful feedback, it is very appreciated. I know I took a while to respond; we talked a lot about your feedback internally.

    @AndrewKaninchen

    I understand what you mean. We seriously thought about having a built-in message system in Timeline, but decided against it. Let me backtrack a little bit.

    When starting the Timeline Events feature, we saw early on that there are two main ways to implement events: Messages and Signals. The first one has all the data on the caller side, like Animation events. On the other hand, Signals let the callee manage what to do. Both have very valid use cases and both also have different setups. We decided to take the direction of Signals for the following reasons:
    • Flexibility: The decoupling between the emitter and the receiver enables a lot of use cases.

    • Reusability: Multiple timelines can use the same set of signals.

    • Multi-user workflow: The signals system can let one user create a set of signals and receivers. Another user then has a list of predefined signals that can be used to build a timeline. Having the signal assets independent of the timeline asset helps tremendously when working with big teams.

    • Ease of use: We saw that having all the reactions in the same object (the receiver) makes it easier to debug. It is also easier to follow what’s happening in the timeline because there is a clear separation between who reacts and who triggers a reactions.
    We strongly believe that the Signal system is the best way to trigger events in Timeline; we think this is what users should strive for, once the initial hurdle of understanding the three piece workflow is gone.

    It’s a tough balancing act for sure and that system may not please everyone. Using the Playable’s Notification API, it is possible for users to implement their own version, tailored for their workflow and their game if the built-in version does not fit. We also plan to release a package with code examples for Timeline (like an updated version of the Default Playables from the Asset Store), which will contain new types of markers, so that you can take those and reuse them.

    Signals Assets are just an id; they are the link between an emitter and a receiver. In your example, yes, you would need a different signal for a each different explosion. In our design, the role of the Timeline is to say “a big explosion happened’’ and it is up to the scene objects to react to that and to activate the correct subsystems (particle, audio, etc.) with the correct parameters.

    You are right, it is an issue; the dropdown could fill the whole screen height and it is hard to search for the correct signal in that case. We’ll address that for sure.

    We want users to be able to reuse signals between different timelines and to be able to create signals even before the timeline itself exists. Having signal assets embedded in the Timeline itself removes the ability to do that.
     
    Last edited: Dec 20, 2018
    recursive likes this.
  17. julienb

    julienb

    Unity Technologies

    Joined:
    Sep 9, 2016
    Posts:
    112
    Yes, SignalAsset can be extended. If you want to add properties that will be picked up by the receiver, you can do so. However, you will also need to write your own receiver. You can also extend SignalEmitter to add custom data if you want.

    No. You can have multiple receivers bound to the same SignalAsset. Also, let’s say you have a track that has a binding and signal emitter. If you put multiple receivers on the bound object, all the receivers will receive the signal.

    image2.png
    In my example here, both Signal Receivers will receive MySignal.
     
    Kiupe likes this.
  18. andybak

    andybak

    Joined:
    Jan 14, 2017
    Posts:
    41
    > Signals Assets are just an id

    then

    > We want users to be able to reuse signals between different timelines

    I might be misunderstanding here - if signals are just an ID then what's the benefit in enabling reuse?
     
  19. julienb

    julienb

    Unity Technologies

    Joined:
    Sep 9, 2016
    Posts:
    112
    Let's say you have a signal Asset Explosion in your project and you a receiver in the scene that reacts on the Explosion signal. Any timeline can send the Explosion signal; you can reuse that signal in multiple timelines. If the receiver is correctly set up, it will receive the Explosion signal, regardless of which timeline sent it.

    Concretely, it lets users work on multiple timelines at the same time while still using the same set of signals.
     
    tarahugger likes this.
  20. AndrewKaninchen

    AndrewKaninchen

    Joined:
    Oct 30, 2016
    Posts:
    53
    @julienb, thanks for the response, even if it took some time.

    I do understand the advantages of the system and, given that you agree the dropdown problem is a thing and plan to solve it, I do agree it's the best overall approach.

    What I still don't like about it, though, is the fact that it is obligatory. There are usecases for embedded signals and messages. Most signals I can think of actually make more sense if embedded in a Timeline. What I think should be possible is the choice between embedding them or not, and the ability to Convert between them automaticaly, kinda like how Bolt allows you to do between Embed or Macro sources.

    upload_2018-12-20_16-15-10.png

    And the thing is, the workflow around it would not even differ a lot. It's just a matter of allowing Signal Assets to be embedded into Timeline Assets and have Signal Emitters and Receivers choose between a "global" list of signal assets or the one from inside the TimelineAsset itself (in the case of Emitters) or a given Timeline Asset (in the case of Receivers).

    If you started using an embedded approach for simplicity and later decided to give the event for someone else to work on while you are still working on the Timeline, a simple "Convert" button would give you the dialog to create the Signal Asset outside of the Timeline Asset and fix all references on emitters and receivers to follow the new approach.

    The same thing could actually apply to Timeline Assets themselves, and to most other asset dependent approaches, like Post Processing Profiles or Animator Controllers. These don't have much of the same problem as Signals are bound to have, as the amount of assets you create for each type is probably not that big for any given project, but to have that extra bit of control would be marvelous for dealing with huge amounts of single-use assets.

    I don't know how you would solve the dropdown problem, but I do think this is a good direction for it. It's not direct messaging, which would still be nice for the simplest of things, but it doesn't complicate the system any more than it should. I'd argue it even simplifies it. And it would be compatible with other ways to aggregate Signal Assets.

    Well, I think that's all I have to say for now.
     
    Last edited: Dec 21, 2018
  21. Vectrex

    Vectrex

    Joined:
    Oct 31, 2009
    Posts:
    203
    I agree with everything said here. It's really more of a UI issue.
    How about allowing the user to directly enter the parameter values like the old system, but for each DIFFERENT set of parameters you'd just generate a new file. You could pop up a dialogue if this was too much 'magic' for UX purposes.

    I also agree with @AndrewKaninchen that the option of embedding the actions in the timeline itself is good, because I'd guess a lot of use cases would be unique to that one timeline (eg your example of footsteps) and yet more files to organise isn't good if it's never going to be reused. I'd default it to embed even. "Nodecanvas" allows embedded or files, for its BT's and FSM's and it's very handy.

    I actually think all animations/timelines should default/have the option to embed the animation file into a GameObject. To allow tidy one-off animations. eg a simple cube turning, shouldn't generate external files to manage.
    A lot of people will use an AnimationCurve to get the 'embedded animation' feature. This is a nasty hack when the animation window should be better 100% of the time (ps Animation/AnimationCurve etc component should output c# events for generic value data). Unreal does this well with the generic Timeline node (BUT you CAN'T separate that into a reusable file, so a convert button would be great)
     
    Lars-Steenhoff likes this.
  22. andybak

    andybak

    Joined:
    Jan 14, 2017
    Posts:
    41
    If you always solve the most general case, it comes at a cost for the common case.

    "Simple things should be simple, complex things should be possible."

    Beauty, clarity and readability in API design is often way too far down people's list.
     
    Shorely and Lars-Steenhoff like this.
  23. Ludiq

    Ludiq

    Joined:
    Mar 6, 2015
    Posts:
    499
    Funny you'd bring up Bolt, I'd been following this thread very attentively for another project of mine. :p

    I agree with all your feedback, although I'm not too worried about asset cluttering or the dropdowns. The easy solution is just folders: place your signals in proper subfolders, and have the signals dropdown respect folder hierarchy as submenus. (Although I doubt that UI quirk will be fixed anytime soon, seeing how the dropdown menu for Script Execution Order or even long enums like KeyCode have been horrid to navigate for years and nobody did anything about it. There's a reason why Odin and Bolt both include their own dropdown/fuzzy finder!)

    What does bother me is that I fail to see the benefits listed by @julienb (flexibility, reusability, etc.) outweighing the abstraction that would be provided by parameters. The lack of parameters & arguments will probably mean I'll never use the built-in signal system. And I mean that. In almost all my use cases, I need some configurable float, string or game object to be passed along the event, something that Animation Events and Unity Events both already allowed. That's what made them powerful: abstraction, albeit rudimentary. Design-wise, this seems like a major regression.

    What puzzles me to no end is that the timeline team went to great lengths to introduce the concept of object bindings, which allowed scene reference from asset files. (That's amazing, by the way!) But the signals architecture goes in the entirely opposite direction, by using scene-agnostic assets instead. With bindings, it seems to me that triggering Unity Events (with or without parameters) directly on the track binding would have been trivial, both to implement and to use. With signals assets, emitters and receivers, there's much more bloat inside the engine and a lot of new concepts to learn for users, on top of the existing Unity Events and Animation Events.

    As a long-term Unity user I'll find my way around (or rather: I'll implement my own markers that send UnityEvents directly to the track binding), but I can't imagine a beginner being presented with animation events, Unity events, signal assets, signal receivers, and signal emitters and having to figure out which piece of the puzzle matches the other.
     
  24. Lars-Steenhoff

    Lars-Steenhoff

    Joined:
    Aug 7, 2007
    Posts:
    1,807
    @Ludiq please consider releasing your solution so others can make use of it too, sounds like you really know the use cases well.

    ( If unity does not implement something like you mentioned )
     
    Last edited: Jan 4, 2019
  25. sebastienlh

    sebastienlh

    Unity Technologies

    Joined:
    Sep 22, 2017
    Posts:
    4
    If I may chime in, there seems to be some confusion about the signal assets.

    The assets are only identifiers, think of them like the tags or layers systems: arbitrary project-wide predefined names. We wanted to allow users to either predefine signal names or create them on the fly while editing. We also needed a way to allow for mass renaming signals. We went with assets to allow for a drag and drop workflow: drag a signal asset on your timeline and it will create an emitter.

    It is important to keep in mind that the asset is not the emitter; the emitter is owned by the track (it's a bit more complex than that, but it's a good way of thinking about it). The asset is the "name" that the emitter uses to bind to a UnityEvent that resides on the receiver (the track's binding or the director). This is a normal UnityEvent to which you can add different callbacks with or without payloads.

    Hopefully, that clarifies things up a little.

    We strongly encourage you to come up with your own solutions if after playing with signals for a while, you decide it's not what you need. However, I think it's worth trying the signals system as-is first.

    Please see this thread about markers customization to get you started: https://forum.unity.com/threads/new-in-2019-marker-customization.594712/
     
    starikcetin and Lars-Steenhoff like this.
  26. andybak

    andybak

    Joined:
    Jan 14, 2017
    Posts:
    41
    @sebastienlh If signal assets only exist to allow consistent naming and mass renaming isn't that the rather a case of "using a sledge-hammer to crack a nut"?

    I assumed that anything using an external asset did so because a) that asset had a certain degree of internal complexity and b) there's strong reasons to allow reuse between scenes in a way that isn't handled by other means such as prefabs etc.

    The cognitive and management overhead of having standalone assets is fairly high for something that's basically a string.

    (Even in cases where a and b where valid assumptions I've found creeping assetification (to coin a phrase) just makes life harder. I've now got to carry a complex mental list in my head about what's safe to edit without breaking other scenes and what isn't. Looking at you post-processing... Now add in version control and multiple people working on a project - there's loads of fun to be had :-( )
     
  27. sebastienlh

    sebastienlh

    Unity Technologies

    Joined:
    Sep 22, 2017
    Posts:
    4
    @andybak Having simple configuration assets has always been encouraged in Unity. I think there is a lot of added value to having “basically a string” that you can drag and drop, reference, pre-define, organize based on the needs of your project, etc.

    We have spent a lot of effort making sure Signal Assets don’t add any more cognitive overhead than Tags or Sorting Layers do. In fact, there should be even less overhead to using them since they are part of the Asset Database. The tooling is built around the idea that you can do everything from the Timeline and Inspector windows, without ever touching the created assets if you don't want to.

    This is a new way of solving an old problem: play around with it and see how it goes. Maybe you’ll find that you see the appeal, or maybe this will solidify your position. Whatever the case, we’d love to hear more about your experience.
     
    Lars-Steenhoff likes this.
  28. zIyaGtVm

    zIyaGtVm

    Joined:
    Dec 27, 2017
    Posts:
    57
    That's also what I want to say.We need timeline signals badly.
    Will Timeline be a part of PackageManager someday?So that we could upgrade timeline features individually.
     
    Lars-Steenhoff likes this.
  29. seant_unity

    seant_unity

    Unity Technologies

    Joined:
    Aug 25, 2015
    Posts:
    645
    We've taken a step towards that in 2019.1. Timeline is now a built-in package. We'll be working to decouple it further from the editor and become a full package in the future.
     
    zIyaGtVm and Lars-Steenhoff like this.