da2020

Update - interesting observation/discovery: I used the generic object as tween target object approach suggested to get the high precision values for x and y, to support the point to point distance calculations in this bezier "flow" animation. It did work fine and yielded the high precision values expected from a non-display object, and it did marginally improve some of the "dithering" I had before on the scaling being performed. But, the most noticeable scaling fluctuations were still present in places where this should not have been occuring. In certain portions of the path, the animated graphic objects would gracefully shrink and then grow (technically they were slightly slowing down and speeding up, but my scaling was masking that visually). So rather than the shrinking only occurring in tight turns/sharp corners of the path as intended, it was also occurring in shallow parts of the curve where it should not, specifically in areas where there was a transition from a straight path into a shallow curve (before reaching the most curvy zone where the anchor points were located). Since I'm using timeline.time() to set the evenly spaced animated graphic positions along the path on each frame, it was as if there were some slight non-linearities in the time vs distance-down-path relationship. Which then made the thought of the bezier's "time resolution" pop in my head. I had set this value to 10 long ago, thinking that was a "very high" value that would assure near-perfect time/speed linearity throughout the bezier paths (and it appeared to when I was just bezier-tweening single objects down the path -- so have not concerned myself with it since). But, with these closely, and precisely space objects used in this "flow" animation, the value of 10 turned out to be not high enough. Long story short, I needed to kick it up to the 25-30 range for these fluctuations to no longer be noticeable --- now it appears rock solid, and the scaling only occurs where it's supposed to (which actually means the time-distance linearity is now close enough to "perfect". I would never have guessed that values above 10 for time-resolution would have ever been necessary, but they were in this case. It was also fascinating (to me) to see how predictable/repeatable the locations of the non-linear "distortion zones" were with the value at 10 -- always in areas where there was a transition from straight to slight curve or vice versa, but not really noticeable anywhere else... Anyway, I think the problem is solved with these changes, and for anyone looking to use timeline time settings to position a series of closely spaced graphics in an animation, it's good to know that time-resolution can have noticeable influence at values well above 10. I was concerned that the higher values (30) that I ended up needing to use would increase the processing time/cpu load, but I have not noticed a significant difference in cpu load so far (most of the load is from vector engine work involved in moving the many pre-drawn objects along the path, with smoothing to avoid a horrible look, and transforms for rotation (path orientation) and scaling). - Doug

Thanks Jack -- very simple and effective solution, where the flexibility of the tween exceeded the flexibility of my brain I had a blindspot in my thinking that the bezier's tweening of "x" and "y" properties needed to be the standard x and y coordinate properties of display objects. Turns out I'm already using a proxy tween object, and tracking via onUpdate as above, for registration point offset/centering purposes, but both those objects need to be display objects since the proxy has to serve as a container for the target. Nonetheless, I should be able to just make use of the generic object as you suggest as a proxy for the proxy.

This is beyond the scope of normal tween use cases (yeah, I know, what a surprise), but I have a need to precisely measure the straight-line distance between two points (ie, two timeline "time" values) along a bezier tween (which is nested in a timeline). I'm doing it now by setting timeline's "time" to point A, and then to point B, and recording the x y properties of the invisible tween target object at each point -- then it's just a matter of doing arctan2 on the diff y and diff x -- works great generally, but.... This distance calculation's accuracy is limited by the .05 pixel "twip" resolution (hence, round off error) that any flash display object's x and y properties are subject to. This resolution is fine for most purposes, but, in this case, that distance value is being used to dynamically alter the length (via scaling) of objects as they move along the bezier path ---- the .05 round-off error on these two points results in small, but noticeable (and undesired) fluctuations in the length of the objects moving along the path where sharp turns don't even exist (due to this random round off variation at various positions). Using a threshold to be less sensitive to this variation is one solution (but this has other issues). Anyway, I'm pretty sure that I could eliminate this problem if I was using the high precision Number type values that I suspect the tween uses internally to drive the tweened object's position. So, wondering if there is, without much fuss, a recommendation as to how these values could be accessed. Or, I'm certainly also open to a better way with the regular API, if there is one. For anyone that might be wondering, the purpose of all this is to make a series of graphical shapes that are following a bezier path (where "flow" is being simulated), such that, when these objects encounter a tight turning radius or sharp "point" in that path, they gracefully "shrink" (length-wise) in order to better track the path at that sharp turn point, and then grow back to full length as they come out of the sharp turn.. Essentially, I'm populating a bezier with evenly spaced graphics that "flow" down a path, like the 2D path plugins provide built-in support for when using circles, ellipses, and rectangles -- but since the bezier plugin does not support such populating and animation, I'm rolling my own solution based on the bezier plugin. As I said, this scheme already works fine except for the issue above, so there's really no need to worry about why I'm doing this if you don't follow my "purpose" explanation... I'm just looking for a suggestion on getting to those high precision x/y tween positioning values. Thanks, Doug

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).. http://codepen.io/anon/pen/xbgpj 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

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

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?

Jack, The "to" helper definitely was not working in the fla (same surrounding code as the fla I posted above) -- there was no movement/tweening whatsoever. Anyway, I just found and fixed the problem - it appears. I vaguely remembered reading/hearing somewhere that the "to" helper uses tweenLite, not tweenMax (a "lightness" design choice I suppose). Well, since I was using tweenMax in my "add" statement, I didn't need to have a BezierPlugin activation statement. When I switched to the "to" helper statement, apparently the tween did not run because tweenLite does not automatically activate the plugin.. so simply adding the activation statement did the trick. Let me know if that theory isn't right. Weird that no kind of error was thrown though. Great news on the throwProps initial value solution.. thanks for getting to the bottom of that. I mentioned early on that I felt it probably had something to do with the math being too close to 0, for too long, with powers greater than 0, but had no idea where it was breaking down internally. I'll check it out, but I'm sure it will be fine as your explanation sounds very solid. Thanks much. So, given this solution approach, is the March 12 version of the bezierPlugin you provided still a better choice than the Feb 26 version? For future reference, what/when causes the uploaded file size limit to reset for a user on this forum? I thought about posting another FLA but saw that I only had 40KB left over from the 460K that was uploaded in a prior post... does that reset by day, by thread, or something else? (I had assumed the 500KB limit was per post, but apparently not). EDIT: I see in my settings that it looks like I have a total of 500KB, period, and will need to delete attachments to free up space when needed... no problem. Doug

By the way, a baffling side issue I ran into when preparing the demo fla above. Like was used on your codepen (that obviously works fine), I initially used the "to" helper as shown below, instead of the add method that works fine in my attachments above (all other code is the same). This "to" statement just will not work in my fla...I get no errors, but the tween simply doesn't run when the restart is issued, or at all even if not paused. I stared at the syntax... can't see anything wrong with it... is this not supported in AS3 or am I missing something obvious? bezTimeline.to(pathObject, 8, {bezier:{ type:"thru", values:[{x:150, y:200}, {x:300, y:90}, {x:500, y:320}, {x:650, y:150}], autoRotate:["x", "y", "rotation", 90, false]}, ease:Linear.easeNone});

Jack, If it's still helpful, I've attached a greatly simplified fla, and swf (compiled with your latest plugin version) that demonstrates the AR rotation initialization problem, exactly as described above. The timeline/tween/easing setup is essentially per your codepen above. The timeline is paused initially. Pressing the "Set..." button will do timeline.time(.00001) and cause the object to rotate in place to align with the path (without starting the timeline). Pressing "Go" runs the timeline. Reset button allows you to repeat the process from scratch. Note that I have ease set to Power0, so that it works (as mentioned, there is no problem when there is no ease/linear). If you set the power to 1, 2, 3, or 4, the "Set..." button's action no longer works -- to make those work you need to raise the .time() setting in the button handler to a much higher value in the range of .01 to .2, depending on the power -- these "high" values are problematic for low/0 power eases, as the object is taken off its starting point by a noticeable amount. If you recompile this with the baseline v12 bezierPlugin (mine's from Nov 2013), everything works fine, ie, all powers work at .00001. Hope this helps. Doug EDIT: Changed the attached SWF to one that was compiled with Power1 ease to show the "Set" button NOT working; the FLA has the ease set to Power0 which does work, bezierTimeInitTest.zip bezierTimeInitTest-SWF-SHOWS_PROBLEM_WITH_POWER1.zip

Sure, I can provide a sample if you still need it. Yes, the value is .00001, and the problem with powers 2-4 persists with values all the way up to .01 or even higher. And, remember that it all works great at .00001 if I use the standard v12 bezierPlugin, as of Nov-2013 (without the restart saved value init fix)... The reason I need something closer to .00001 rather than much larger values is that, with longer paths, and with higher path speeds, that time percentage can be big enough for the the object to jump off the starting point by 10's of pixels (especially if it's a linear no-ease case), causing a noticeable jump away from the actual starting point. Standing by....

Jack, With the new plugin, it does still solve the February problem (restoring proper initial position after a timeline restart despite downstream beziers with AR enabled), but the recent problem of not responding to very small initial time values to set the AR angle is still there. Meaning, with .00001 (which works with all easing powers in the baseline v12 plugin), the starting AR rotation is still not getting set with any ease power from 1-4 -- it does work, though, with linear power0. With some quick tests, I had to run the timeline.time() value up to around .01 just to get power1 to work, but even then powers 2-4 would still not work... so that behavior seems to still be similar to the that of Feb 26 version. In case you're wondering, the test case would be just like what you have set up in your throwProps easing codepen above, but with the controllerTimeline paused at the start, setting controllerTimeline.time(.00001) (or whatever very small number) and then observing that the object is oriented to point down the path while still sitting at the starting gate... if you do that, you should see that linear ease works, but if an easing power of 1-4 is used the object does not get set to the AR value with that small time setting, unless you jack it up into the .01 - .2 range, depending on the power... hope that makes sense.. (as a reminder of why, the author that uses this tool is able to drag the points and thus curve shape around, while the timeline is "paused", and see the object's rotation track the path's departure angle from the starting point, and this also sets the object's position in the "published" runtime mode such that the object will be pointed in the right direction even before it's launched to travel down the path) If the solution isn't obvious or too much of a pain to pursue, no sweat, I can make do with the workaround I've got... I realize that the combination of things I'm trying to do is probably very unique to my application.

Jack, Think I isolated a contributing factor as to why my timeline.time(.00001) approach for initializing the autorotation of an object was no longer working when using throwProps-based ease-in at the start of the path (as described above): When you asked just above if I was using v12, and I answered yes, it slipped my mind that I was actually using a bezierPlugin v12+ version that you supplied me 2 weeks ago. In one of my earlier threads ( http://forums.greensock.com/topic/9103-bezier-tween-autorotate-behavior-when-in-a-timeline-series/ ), you supplied that special bezierPlugin build (February 26) for me to fix an issue that you agreed was leading to counter-intuitive autorotate behavior when restarting a timeline. I had a hunch this might be causing the AR initialization problem above, since you seemed pretty confident that vanilla v12 should not have this problem. Sure enough, when I swapped back in the baseline v12 bezierPlugin (v12 as of Nov 2013), the initial AR rotation scheme ( using time of .00001) then worked fine for all types of throwProps-based eases. It would seem that the fix to save and restore initial object properties when restarting is interfering with the ability of the small time values to set the object's AR rotation. It's up to you -- if you can see a simple remedy in the plugin design, that's great, otherwise I can live with my current solution, which is conditional logic that uses timeline.time(.2) to set AR rotation when higher power eases are involved (that's how far into the timeline you have to go to get AR rotation when power3 or 4 is used). In any case, I appreciate the Feb 26 fix, since it solved a different, potentially more important problem in how AR is initialized after a restart. Thanks, Doug

Thanks Jack. I'll give the getRatio approach a go -- the issue is really just one of being able to set up a predictable duration for the throwProps-based easing period. Yeah, everything is v12, as purchased and downloaded last November. Actually, I was running fine with an initial time value as small as .00001 for setting the AR-driven rotation when the timeline was running beziers linearly. It's only when the up front ease is introduced to that same bezier timeline (per the throwProps code exactly as above) that this threshold needs to be raised significantly... and the amount it needs to be raised is proportional to the power of the ease (ie, the extent to which "near-0 motion" persists at the start of the timeline). The AR works fine in all other respects once the timeline begins playing. I think I can get by with the workaround I alluded to above -- just set the orientation using a non-eased timeline, then swap in the eased version.

Hi Jack and all, Wanted to provide some updates, and ask a question, after incorporating Jack's general solution, described above, in my app. The approach does work very well in terms of providing a seamless ease in and out with no undesired jumps in speed at the borders of the eases and the central part of the timeline. One practical issue I've been grappling with in my application is the user experience aspect of selecting the ease-in and ease-out durations. If the user is editing a path that is 10 seconds long, and wants the speed to ramp up in 2 seconds, and ramp down in 2 seconds at the end, they would enter these as the desired durations for ease-in and out (and would also selected a desired easing power). The "problem" is that, since the actual duration of the easing periods has to be calculated due to the slowing caused by any given power of easing, the ACTUAL duration of the ramp up and ramp down periods isn't just a little different than the 2 seconds desired, but can be a LOT different, like around 2-3 times as long... So, one might be expecting, or wanting, 2 seconds to ramp with some easing power selected, then 6 seconds at the constant "linear" speed, then a 2 second deceleration using some easing power; but, if they choose a stronger ease, like power3, they'll actually get a ramp-up and ramp down duration of around 4-5 seconds each, leaving almost no time for the middle constant speed period. I was able to solve this using the crude "goal seek" loop code shown below (this code is for the path's starting ease-in... similar code was used for setting up the ending ease-out). This simply determines the approximate adjusted, and non-adjusted ease duration values (both are needed) to produce an ACTUAL duration that is close to the desired/entered value (where easeInDuration is initialized to the user's desired time value) While this works, I'm wondering if Jack or anyone can see a more direct way of arriving at this target value for a user-specified actual duration (entered at runtime)? //when added before Jack's code above, this loop provides an easeInDuration value and adjustedEaseInDuration value that will approximate the actual duration of the ease period (again. a crude approach, happy to improve based on suggestions): for (var d:int = 11; d > 0; d--) //number of loops is just a matter of how much precision is needed in the approximation { testDuration = easeInDuration / d; //easeInDuration equals user-specified actual duration target adjustedEaseInDuration = ThrowPropsPlugin.calculateDuration(0, testDuration, 1, ease); if (adjustedEaseInDuration > easeInDuration) { easeInDuration = testDuration; break; } } P.S. These 2 items are other things I'm grappling with, using the new throwProps approach: 1) I'm also still piecing together how to adjust to an actual total path duration (also user-specified), given any user-entered ease-in and out durations and ease powers... this would require dynamically adjusting the linear constant speed for the middle to achieve the needed overall duration -- I suppose it could be done by calculating a factor based on how much "over" the actual total duration is relative to the desired total duration, and then applying that to overall timeline's timescale.. not sure.. any thoughts on that welcome also). 2) Also, per a prior thread, I'm using a timeline.time(.0001) (or similarly small value) to set the initial rotation of the object, when timeline is still paused and object is sitting at the starting position, so that it aligns with path when the bezier's autoRotate property is enabled. I'm finding that with the new reverse throwProps trick for accomplishing ease-in, this approach to setting the initial pre-motion rotation of the object no longer works unless I use a much larger value, like timeline.time(.1), which make the object move off its initial position by a noticeable amount under some situations.. I think this is because with higher ease-in powers, the motion at that very early point remains so close to 0 that no autorotation is calculated... I say this because only higher easing powers need a higher initial time value to set rotation... My workaround may need be running the original timeline.time(.0001) against a straight timeline without the ease-in applied (just for setting object's initial rotation if AR enabled) and then immediately replace that straight timeline with the throwProps version that adds the easing... I think this will work. but clunky... do any cleaner alternative approaches come to mind? . Thanks, Doug

yep -- i can run with that -- very cool and impressive. I may even incorporate this down at the individual bezier timeline level to give flexibility on how motion easing can be optionally used for each of the bezier "segments" in the path. After seeing this, thowProps is probably one of the most underrated plugins as far as solution potential Thanks to everyone for the thought, demos, and explanations! - Doug