I am trying to work out a custom track type where each clip defines where a Transform should be positioned. The dead space between the main clips should be used for movement between the valid positions. I am ok with needing a separate kind of clip “target is free to move” vs “target is stationary at point X”, and using those movement clips to fill all the dead space between the others.
The problem is, for any given time T during the dead space or “movement” clip period, I need to peek ahead to the next “stationary” clip to figure out where I am moving towards, not just when. I don’t want to have to overlap clips to achieve it in mixing, because of the way the interface favors the time the mixing period begins instead of when the mixing period ends and the “stationary” clip is actually stationary at full mix weight.
As a poor analogy, the game Musical Chairs has you moving during music, then WHAM, music stops so you need to stop. If you could peek into the future, you could ensure you were in a valid chair exactly when the silent period began.
I’d recommend actually walking through the clips and extracting the relevant data (such as the clip start/end times and your custom position), and passing that directly to your custom mixer when you create it, instead of trying to look at the inputs inside the script. It’s likely going to be easier and faster that way.
Basically use the mixer to do all the computation. No need for clip playables.
To get the timeline time you can use playable.GetGraph().GetRootPlayable(0).GetTime(). The time on the playable passed to the Mixer in PrepareFrame()/ProcessFrame() may not be accurate.
If your transform is bound to your track you can then write the computed values.
Okay, that makes some sense here. Ignore the inputs, pay attention to the clips. I’m still reading through the API to understand how to get to the timeline track itself and walk all the clips.
The key thing that I discovered through these experiments is that the mixer is getting ALL the inputs in the whole track, not just all the inputs which overlap the current frame. Most of the inputs in a long track simply have a 0 weight for the current frame. I had thought there must be a possible bottleneck here when you scale up to timeline tracks with many thousands of clips, but only 1 or 2 are able to affect the current frame, so I had just assumed that the mixer was only shown the clips with non-zero weight to begin with.
In this thread, I found a good bit of code by @Razouille to construct clips by code, which will come in handy.
Even after several re-readings of the tutorials out there, I don’t know why I had not run into the “Default Playables” asset on the store. This includes the Light Control track that is documented in the tutorials, but also includes other useful custom tracks like the TransformTween track.
With the code from TransformTween, the code from Razouille to construct timelines from code, and the ideas @seant_unity gave above, I think I am well on my way for my custom mixer.