I am currently using Timeline to control individual characters in a fighting game, and must manually control and evaluate multiple timelines per frame. Any given timeline may be stepped or evaluated multiple times per FixedUpdate, due to needing to support rollback netplay. It is working well, but it is generating a lot of garbage. Each call to PlayableDirector.duration and PlayableDirector.Evaluate both generate 80 bytes of garbage per Timeline. With up to 8 timelines in use and potentially 60 ticks to fast forward as a result of rollback netplay, that can generate 76.8kb of garbage in one (Fixed)Update. My question: is this garbage necessary? and if it isn’t, can this be removed?
Tangentially related: is it possible to run these evaluations as a part of the C# Jobs system?
It’s the latest 2017.3 release. It should be noted that I do swap out the playable asset on occasion as a part of a state machine I built around the Director, and it is rebuilding the timeline playable at transition points, but this GC is happening at every update tick, not just the ones where the timeline is changed.
It’s often more efficient for UT if you attach a project to reproduce the issue. The easier it’s for UT to reproduce an issue, the more likely it’s that they’re actually going to look at it.
As an alternative to this, I’m experimenting with try to create a single playable graph instead of swapping out timelines. I have a large number of timelines, on the order of 80-200 per object playing it. The end result is something similar to a code-based Animation Controller, except with the base elements based on Timelines instead of simple Motions. With only one or two of the timelines having non-zero weight, are there potential performance issues if I attempt to merge all of those timelines under a single playable graph?
I don’t think there will be any difference in performance. We get asked frequently questions like ‘how many timelines/playable graphs can be played at once’ and the answer is it’s less about the number of graphs and more about the number of outputs (i.e. tracks) in total. Each output has a subgraph that is traversed and processed.
E.g. Having 25 animation tracks running is roughly equivalent to having 25 animation controller playing. The cost will be dependent on what is being animated.