achieving predictable speed of bezier tween when easing is used

[da2020]

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

[da2020]

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});

[GreenSock]

Okay, I know what's happening and I have a solution. First, let me explain the whole 0.0001 thing: 

 

Remember how I said that in order to avoid some glitches in Flash and browsers related to floating point precision issues, tweens/timelines will always round a time of less than 0.0000001 to be zero? Well, in our example, we've got the ThrowPropsPlugin tween that is animating the time and we're telling it to start at 0, and it eases up. Consequently, (especially with a strong ease) that can lead to EXTREMELY small decimals at the very beginning, which kicks in that rounding. Technically, it's operating exactly as it should, but it's not quite what we WANT in this scenario. The solution is easy. 

 

Make the throwProps tween animate the "time" from 0.0001 instead of 0. So in that first controllerTimeline tween, the throwProps portion would be:

throwProps:{time:{velocity:-1, end:0.00001}}

That'll fix the entire thing. Jump to any time you want in the controllerTimeline and it should render perfectly.

 

As for your question about the syntax not working in AS3, I'm pretty confused - I tried that exact code and it worked beautifully for me. I wonder if you were just confused because you added a 90-degree offset rotation in that array. Make it 0 and you should see the same behavior as with autoRotate:true. Right? 

[da2020]

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

[GreenSock]

Ah yes - I hadn't opened your FLA because I already was able to reproduce the issue on my end and identified the issue, but you're absolutely correct about the plugin activation. Good find. 

 

And yes, the March 12 version is the best. Use that.