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:
    948
    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:
    35
    This is what Clips are for. Markers are inherently "duration-less" (and in any software).
     
  3. tbriley

    tbriley

    Joined:
    Sep 10, 2013
    Posts:
    113
    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:
    948
    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:
    645
    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:
    528
    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. artemio_morales

    artemio_morales

    Joined:
    Nov 29, 2015
    Posts:
    17
    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:
    145
    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:
    948
    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:
    290
    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:
    948
    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,494
    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:
    528
    @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:
    202
    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,494
    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:
    61
    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:
    25
    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:
    35
    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:
    948
    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:
    290
    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:
    61
    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:
    61
    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:
    431
    @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.
  29. artofmining

    artofmining

    Joined:
    May 1, 2016
    Posts:
    31
    Great feature is Timeline and Signals give greater potential however with respect there's more legwork to make them useable at great length.

    I am desiging a Unity system to help me streamline my film makng system. I basically have a setup where I can drag mutiple characters (Actors) into a scene. Each Actor has a script attached that controls the following:
    1. Head LookAt Object
    2. LipSync to a GameObject Audio Source (via volume levels to blendshapes, quite primitive but good enough)
    3. Trigger various animations on character to emulate emotions. (Combination of Blenshapes and Animations)

    I'm working on using timeline to control these parameters on each character in scene.
    Everything works from one Audio Track which is a vocal conversation track. Overtalking is not a big issue for me.

    Using signals I assign on each character track I can effectively call scripts functions to activate/deactivate lipsync, change Lookat Object and change current animation on a specific Actor (character). Great!

    Problem is managing the signals in an efficient and identifyable way as they soon grow. The biggest cause of this is having to create NEW Signals and RECEIVERS for each such event. Imagine 3 or more characters (actors) in scene chatting and doing their bit. I have many signals at timed events making them respond to the audio lipsync, lookat and animations. Its soon becomes tiresome to see which signal does what even with good naming convention.

    Not sure if this asset will help but I'm going to look at it - https://assetstore.unity.com/packages/3d/characters/timeline-events-115300

    The Signals would be better if there was something easier to follow on timeline and reusable in some way. i.e. One Signal that I could copy and paste and set some custom events on per what I need to control on a that character at a given time. Some form of customisable Signal otherwise they are quite restrictive in heavy useage.

    Just a thought!
    Cheers
     
  30. Cameron860

    Cameron860

    Joined:
    Jun 1, 2009
    Posts:
    765
    I understand why you'd want a system with separate signals and emitters, but to blow off the simplicity of a system like animation events and to claim that's not the right way to do it is really frustrating. There's a lot of power in a system being simple and intuitive and for me the intuitive nature of systems is what I loved about Unity back in the 3.x and 4.x days.

    I also don't see a reason why you can't support the legacy animation event workflow within signals. Let signals be defined as simple POD types (no behaviour) that can define serializable properties that are exposed and saved in the timeline. Then let signals on clips emit and bubble-up to receivers above them in the timeline hierarchy. Then you can just have a root level receiver to route all unhandled signals of type x to method y and you handle the most common case of animation event systems of a many-to-one relationship without a convoluted, confusing and really slow workflow.
     
    awesomedata and Lars-Steenhoff like this.
  31. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    948
    Seconded. :)
     
  32. artofmining

    artofmining

    Joined:
    May 1, 2016
    Posts:
    31
    I built these videos using a system I have been developing in Unity .. it allows me a piecemeal of flexibility wotking from one single vocal track (the 1st step) to which I then timeline my characters to respond via events and call from a number of public functions Ihave coded. Basically it ends up a realtime animation system to which I then render/record to MP4 1080HD. The only minor issue is that it disables audio while rendering (for efficiency I guess) so its not so great if I want to do some realtime control like cam move or control a particular character. But all in all Unity has now become my film making system rather than using iClone which I hated.

    It's a constant work in progress system (more a suite of tools) I've been developing for the past year. Plenty of new ideas that I'll add as time goes along.





     
    Lars-Steenhoff likes this.
  33. Ferazel

    Ferazel

    Joined:
    Apr 18, 2010
    Posts:
    379
    I realize I'm late to the party, but I'm finally on a project where I can use Timeline and signals. I'm disappointed that this is the best that Unity could have done with this system. I'm working on a system using signals that need to allow for branching timelines based on dialog choices and I thought I could handle that with signals when the end of the timeline needs to move to another branch. If I define these branches in an array for a given cutscene monobheaviour, there's not a good way to use specific branch logic without creating signal for every index possible in the game. (Branch0, Branch1, etc.) When honestly this could have been resolved with a single emitter that has an index argument BranchX.

    The whole concept of a reusable "signal" object doesn't make any sense to me. I'm not sure I buy the argument that decoupling the receiver from the signal was a good idea, since you need to define the target object receiver, and on the receiver bind that signal to a method call (direct coupling). What's the abstraction benefit here exactly? So that you can reuse an emitter type in multiple timelines? Great, but you still need to do the leg work of binding those signals to specific receivers thus creating coupling. The idea of reusing timelines and dynamically rebinding the output of tracks is a use case that is much more infrequent that you think it is. Should dynamic rebinding of signal targets be supported? Absolutely, but do it through code (which you need to rebind the track to a new object anyways)! Should it make the primary use case of the signaling system more convoluted/less flexible as a result? I would definitely say no.
     
    Last edited: Feb 3, 2020
    awesomedata likes this.
  34. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    948
    This is kind of why I still feel this whole project was half-hearted in its final execution. I think branching Timelines is a very good use-case for Timelines even in their current state. Their design, however, makes this use-case very difficult as you have already mentioned.

    I can imagine making a general Timeline that "branches" by "becoming" a specific Timeline (depending on a choice), but in this use-case, Timelines would need to be treated as a sort of an extendable-prefab system for this to be a nice experience for the user.

    All in all -- Unity is not thinking generically enough for its larger systems, but at the same time, it is thinking too generically for smaller parts of those same larger systems (like the Timeline Signals system versus Timeline itself).

    Pigeonhole features like Timeline Signals really restrains the possibilities of the Unity Editor.
     
  35. OhiraKyou

    OhiraKyou

    Joined:
    Mar 27, 2012
    Posts:
    245
    After the first time I watched this talk about game architecture with Scriptable Objects, I immediately implemented the idea for event assets that pass calls to listener scripts and, by extension, their UnityEvents. I found that being able to simply drag an event asset into any UnityEvent and call its invoke method, treating it like any other reference, was quite intuitive, convenient, and flexible. Anywhere a UnityEvent exists, I have the option to invoke any number of signal-like, asset-based events. But, I can just as easily use any UnityEvent without referencing an asset. Or, I can do both, referencing GameObjects and event assets in the same UnityEvent. If Timeline events and signals were separate, this would be possible. But, seeing as they're not, I want a separate, basic event.

    This is because basic events are still necessary to account for multiple instances of Timeline-animated prefabs or other procedural content. For example, I've used Timeline to animate enemies, of which there can be an arbitrary number. Indeed, most of the applications I consider for Timeline are for objects likely to be instantiated an unknown number of times. Props and enemies often require small animations and general time-based sequences.

    Maybe a custom marker with a basic event wouldn't be too hard to make. But, it's fundamental enough that it absolutely should be part of the base package.
     
  36. awesomedata

    awesomedata

    Joined:
    Oct 8, 2014
    Posts:
    948
    Someone from Unity did promise some extra kinds of Timeline Event-ish stuff was on the roadmap way back in the old Timeline Events thread (probably because a lot of people were raging then because the events Unity demonstrated before the Jobs system was introduced wasn't at all what was delivered, yet basic events were what everyone was expecting).

    However, they never delivered. -- And, as usual, we're still waiting.
     
unityunity