Comparison with Timeline (Hint: Timeline is not perfect!)

[Breaking Fourth]

Since we’ve done some internal experiments with Slate and Timeline, we thought we’d share our findings and why we’ve decided to stick with Slate for upcoming productions despite Unity pushing Timeline as its ‘official’ solution. Hopefully this should help inform other users’ decisions about whether to use Slate vs Timeline, and perhaps some of this feedback may help inform the design of Slate going forward.

What’s the same?
Both Slate and Timeline are capable cutscene sequencing tools with direct control over animations, audio, support for previewing and scrubbing in edit mode, and giving the user the ability to script new types of cutscene clips. Both integrate seamlessly with the Unity editor, both have the ability to offset the timing of a source playable within a clip, and both have the notion of ‘blending’ into and out of a clip’s effects.

So what’s better about Slate?
Since Slate has been around for longer, it already has a vast library of different types of custom clips to allow users to get stuck in to creating complex and feature-rich cutscenes right out of the gate. Slate also makes it much easier to create new types of clips – not only does its existing library serve as a rich set of code samples, but the architecture of creating a new clip type is much simpler than Timeline. In Slate, the developer just needs to write a new Clip subclass and implement all the appropriate methods for enter/exit/update. When the clip is instantiated in the editor, its properties are serialized with the cutscene into the scene itself. In Timeline, the developer needs to create two classes – one for the storage and instantiation of a Clip (a PlayableAsset), and one for the playback of a Clip (a PlayableBehaviour). It is unclear why Unity chose to design Timeline in this way, but it may be because a Timeline cutscene is serialized as a separate file, not as part of the scene. This has some advantages, but it also has the huge disadvantage that a cutscene may not store any direct references to objects in the scene – the one-to-one bindings between tracks and scene objects are stored and resolved in the scene’s Timeline player component. This means that, for instance, a Timeline clip cannot reference an object in the scene for its track actor to interact with. And a single track cannot influence multiple objects. Slate has none of these limitations. Slate also has a much more intuitive workflow for animating arbitrary parameters of an object within the editor. Slate is intelligent enough to be able to identify most animatable properties of an object through reflection, and these properties can be keyed and curve-edited directly within generic clips or tracks. Timeline has the ability to perform this kind of animation, but it’s clearly designed to meld with Unity’s existing (and inferior) Animation Window, so you’ll be swapping between the two views to perform curve editing, and when you’re done, it expects you to save the resulting animation down to another new file. Slate’s developer also seems to be much more agile and responsive to bug reports, and if you can’t wait for the next update to come out, you already have access to the full source code, so you can always hotfix issues yourself.

So what’s better about Timeline?
The biggest advantage that Timeline has is speed. Since it has been built directly into the editor, it can take advantage of the low-level performance of being compiled in c++. Slate also suffers from performance hiccups when it needs to resolve animations with root motion – every time you scrub or change anything in the timeline, Slate has to re-evaluate all of the animation clips and steering of root-motion-animated actors, and if you have many such actors and many such clips, these stalls can last several seconds – No such hiccups can be seen in Timeline. The fact that Timeline cutscenes are saved as separate files gives it the advantage that cutscenes can be edited independently of the scene for better source control, and re-used between scenes, with each scene only storing object bindings. Timeline has more intuitive support for nesting sub-cutscenes – double click a sub-cutscene in the editor, and you tunnel into it. Although Slate does support sub-cutscenes, its implementation is fairly basic. Timeline is also more generic, since a new cutscene is not automatically created with a Camera track and black bars – instead, camera control is handled by the Cinemachine plugin, which has much richer support for physical simulation of camera properties, and separates the two concerns. Timeline’s support for snapping is much better – where Slate can only snap to the nearest time increment, Timeline clips can snap to each other’s start and end points much like Adobe Premiere, which can give tremendous peace-of-mind when attempting to sync up animation and audio. And finally, although I would not suggest that Slate try to respond to this, Timeline also has the notable advantage of being free.

Conclusion
Although Unity has produced a strong contender with Timeline, Slate’s existing breadth of features, extensibility & maintainability, and lack of limitations still make it our top tool for cutscene sequencing in Unity. There’s no doubt that Timeline’s feature set will improve over time, and ways will be found to hack around its limitations, but if Slate’s runtime performance and foundation feature set could be improved, it could secure its future as the premium cutscene tool for Unity, especially for developers who want to save themselves from creating a ton of boilerplate code.

[sugoidev]

Nice review!

RootMotion issues is something that got us to the 15 seconds mark per scrub with a cutscene!
Baking it is very expensive and it seems to happen fairly often.
This is definitely an area that needs improvement.
With this exception, I never had any issues with super complex cutscenes in SLATE. Even very long ones.

[Breaking Fourth]

sugoidev wrote:

Nice review!

With this exception, I never had any issues with super complex cutscenes in SLATE. Even very long ones.

Thanks!

We did start to see slowdowns in Slate with too many Property tracks, because these tracks update their target property every frame, even when the value is not changing. This can be especially problematic when updating a transform with a deep hierarchy, like an elevator holding several characters. We got around this by switching to using AnimateProperties action clips, which were less likely to overlap with each other.

[Gavalakis]

Thanks a lot for your honest review!
I really appreciate that and I do agree with the cons presented for Slate vs Timeline. Most of the things you mention are things I do certainly want to improve, with root-motion baking performance being one of my top priorities since it’s one of the things that is really bugging me!

The only reason that root motion is baked honestly, is so that the cutscene can stay dynamic (as far as actor position/rotation goes), meaning that the root motion is applied as an “offset” releative to the actor’s “starting” position, instead of “absolute” position/rotation (like it’s done in Timeline). But of course, not everyone needs that to be the case and right now baking is taking place even in those situations where applying the root motion as an “offset” is not required. Having said that though, I will definetely need to accomodate that as an option, and/or improve baking (a lot).

I really hope that this major con is resolved in the next version!
I will also of course try to improve in the rest of the areas you’ve mentioned in your review as well 🙂

Thanks again!

Join us on Discord: https://discord.gg/97q2Rjh

[Author]

Posts