determining the effect of timescale tween on the duration of the affected timeline?

[da2020]

I have a timeline that contains a number of tweens running in parallel/concurrently.  One of those tweens is tweening the timeScale property of that parent timeline.  With a single yoyo on that tween, it works great as a way to introduce "slo-mo" style effects at various points along the timeline (similar to the effect of the slo-mo plugin, but with more control on placement, etc).  

For various reasons, before running that timeline, I look at the timeline's duration, which generally reflects the overall combined duration of the tweens it contains. If there is a target duration being requested for the timeline, I adjust the timeline's timescale property so its actual duration will match the requested duration. This works fine too, generally.

Just one catch that I've not been able to find a solution for: Since the above mentioned tween is tweening the timescale of its parent timeline, I've found that the duration property of the timeline does NOT reflect the lengthening of the timeline's actual runtime duration caused by this tween, even though that timescale tween is contained within the timeline  (I guess that's because the duration is always given in terms of the timescale always being 1, which is fine usually, but not what's needed in this case). 

So, wondering if there is a way to determine the duration (before running it of course) of that timeline that DOES reflect the ACTUAL time that it will run, inclusive of the timescale tweening?

[GreenSock]

You can easily figure out the duration inclusive of the timeScale with:

var adjustedDuration = timeline.duration() / timeline.timeScale()

However, it sounds like you're dynamically controlling the timescale from a nested tween (which is probably easing it too) which makes it pretty much a mathematical impossibility. That's not a flaw or weakness of the platform either - it's just a logical impossibility.

 

Also, the timeline doesn't search all of its children (and grandchildren, etc.) for any possible tweens of its own timeScale and somehow factor those into the duration calculation. Not only would that be pretty much impossible mathematically, it'd kill performance if it had to do all that analysis every time it was asked for its duration.

 

For example, if you have a 10-second timeline that you were going to play at normal speed for 1 second, then suddenly change to half-speed for 6-seconds, and then back to normal speed, you could calculate that the total duration would be 13 seconds, but if you're easing the timeScale from 1 to 0.5 over the course of 1 second, it completely changes the dynamic because the timing offset is constantly changing over the course of that tween. See what I mean?

[da2020]

yeah, that's understandable..   Your snippet's OK for accounting for fixed timescale adjustments outside the timeline, but of course, my need has the dynamic, mathematical challenges you refer to..   Bottom line is I'm just trying to use time-based-tweening for slo-mo type effects that are superimposed on all the other things going on in the timeline -- it's just too cool not to pursue...  and, yes, my nested timescale tween is getting eased by its own action by virtue of being in the timeline that's being dynamically time-scaled (yikes)--- I knew that would be calculus-bomb of great proportions, but you never cease to amaze me, so had to ask.

 

The only Doug-like crude work around I could envision was setting the timescale to make the timeline run super-fast, then run it, and measure the time it took with the nested tween and all, and then scale that measured time back down to its "real" value... Definitely crude, but since this is an editor and not something that happens in "production runtime", it might work...

 

Thanks

[GreenSock]

Yeah, that technique of building your timeline and setting its timeScale to something super high and playing it to see how long it actually took won't work. Part of the beauty of the way the GSAP system works is that it's completely "resolution-independent" (in terms of time) - it doesn't have a set number of "frames" that it pre-compiles or something. It calculates the values on-the-fly according to EXACTLY where you ask it to render. 

 

For example, in Flash, you can build a MovieClip timeline that's 100 frames long and put a bunch of motion tweens in there. Let's say you tween something from x:0 to x:100 over the course of 10 frames; that means it moves 10 pixels on each frame. You're locked into that "resolution". If you slow down that MovieClip at runtime, it will literally just get jerkier because it still moves in 10px jumps. Not cool. 

 

With GSAP, if you told that timeline to render at exactly 43.213%, it would calculate x to be precisely 43.213px. It does it all on-the-fly. So things simply update based on "ticks" which typically run around 60 times per second. 

 

The reason your theory wouldn't work is because imagine how/when the timeline's timeScale would get changed - if you compress things to run super fast, that might mean that instead of getting 100 ticks/updates over the course of the tween (each altering the timeScale, thus affecting the duration), it only gets 2. Of course it would set those 2 to exactly what they're supposed to be, but your duration at normal timeScale is affected by that easing, so it won't have an identical cumulative effect if you make things run super fast. 

 

With virtually all other types of "normal" tweens (of properties like x, y, rotation, whatever), none of this matters - it just renders it precisely as it should no matter how fast or slow you run the timeline. But if you're affecting the actual scale of time with the tween, you're in a twilight zone scenario where time effects time which effects time, etc. 

[da2020]

Jack -

I take your points as to why it "won't work" for the case where there are VERY few samples (frames) over the period where timescale tweening occurs.

But, for what it's worth,  I've actually got this approach working reasonably well for my purposes -- my goal was to be able to determine a decent estimate of the timeline's duration by taking no more than a second or so for the estimation processing (a reasonable "processing" delay from a UX standpoint in this path editor app) for longer motion paths that might otherwise take 15-30 seconds (painfully long) to run at normal speed. You may have thought that I was looking to do it in "near-0" time.

 

Here's an example pen that shows an object moving along a bezier, with 3 consecutive tweening operations -- in each operation, the object rotates 180 as it eases into and out of a "slo-mo" mode (via a nested timescale tween) while it's inverted.   The pen allows you to run at normal speed to see the actual duration (approx 17 seconds, which would be only 10 seconds if the timescale tweening was not applied). Then, you can run at 10X or 20X, and the estimated duration and % error are displayed for each run.  At 20X, the estimate run is less than 1 second (my goal) and the accuracy of the duration estimate is typically within 1% or so (not super-accurate, and not good enough for rocket science, but good enough for editing a path for visual effects on presentation content).. 

 

See the Pen xbgpj by anon (@anon) on CodePen

j

 

 

Part of the trick here was to adjust the timescale tween target to maintain the same ratio with the higher speed timescale setting used for high speed duration estimating (which is fixed for any given run). That way, the faster the timeline was made to run for estimating purposes,  the higher the timescale target used in the nested tween.

 

To your points, the accuracy would/does fall apart if going for substantially higher speeds (like 50X) or if working with paths with very short durations.... But, since I plan to adjust the speed increase factor for estimating based on the untweened path's duration, I would not need to increase speed very much (if at all) for very short paths in order to get under my 1 second goal for estimating time.

 

I suspect that a good part of the inaccuracy that does exist is due to the variation in the time to reach the point where the timer is started and stopped in the first and last frames, since the error seems to be mostly in the ballpark of +/- 1 frame interval. And,  as you said, there will also be some additional errors, even with a 1 second run, due to fewer overall samples. If there were a way to more tightly sync the the initial time recording, and the measurement at completion, with the start of a frame, that might reduce some of the error that does exist.  I noticed also that browser type had a significant effect on accuracy, at least in the pen, where Chrome was most accurate (usually within 0.5% at 20X) and IE11 was the worst, at almost double the average error.  FF was in the middle.

 

Anyway, this is truly a "for what it's worth" posting, as this is certainly not a perfect solution. It's only useful if applied understanding the limits in how it can be used, as mentioned above -- just wanted to pass it along in case others were faced with a need to approximate long durations in some programmatic way without having to run the timeline at regular speed. 

I'd love to find a better way, but can't see a better way to crack this...  Thought of moving the timescale tweening sequence to outside of the targeted timeline (to at least eliminate the added math headache of having the timescale tween slowing down its own timebase), but I can't see a way to be able to drop in these speed transition effects as gracefully as is done here, with the precise positioning (and syncing with other nested tweens) that the nested tween approach provides.

 

Doug