Jump to content
GreenSock

Search In
  • More options...
Find results that contain...
Find results in...
Gabriel

Problem tweening time property

Recommended Posts

This is a really odd error, so please read closely.

 

First of all, here's the code in question:

var tl = new TimelineMax({repeat:-1}),
    mAnim = TweenMax.to(moon,4,{paused:true, ease:Linear.easeNone, bezier:{values:[{left:moon.l(0), top:0}, {left:moon.l(-60.8), top:moon.t(-34)}, {left:moon.l(-100), top:moon.t(0)}]}})

tl.addLabel('sun','+=1')
    .add(TweenMax.to(mAnim,2.2,{time:2.2, ease:Linear.easeNone}),'sun+=2.2')
    .add(TweenMax.to(mAnim,7,{time:3, ease:Linear.easeNone}),'sun+=4.4')

This runs perfectly OK the first time through. The second time through, the "moon" starts 2.2 seconds into the animation and stays there until "sun+=4.4" kicks in, then animates. What I'm saying is that on the second timeline loop, the first ".add" is not animated, but the second one is.

 

OK, so I've duplicated this with the following codepen. I can't duplicate the original, because that would be a **** load of code from two scripts to allow for that. All that code works flawless, and relies on screen size to calculate the 'top' and 'left' properties. So the coordinate value code is really all that's absent from this codepen.

 

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

 

The odd thing about this codepen, even though it uses the same time values as the original, it works perfectly. Although if you swap the commented ".add" function with the preceding one, then this codepen replicates the problem I'm having.

 

Since the same time values work for one and not for the other, and that the problem seems to be from overlapping animations added to the timeline, I can only assume that there's some kind of rounding error that's occurring with my longer bezier curve in my script.

 

UPDATE: I updated the codepen with the same coordinate values logged from my script, but nothing has changed. I really don't get it. Value for value, the codepen is identical to my outputted code, I've triple checked, but it doesn't have the problem unless you swap the commented line in. Mine is animating a PNG instead of the DIV, both rendered at the same size, but I don't see why that would change anything.

 

For now I'm changing the 4.4 delay to 4.401 in my script, which fixes the problem. Must be a rounding error....

Link to post
Share on other sites

Hi Gabriel,

 

I've played  a little with your codepen and when you change the code to this:

tl.addLabel('start','+=1')
.add(TweenMax.to(anim,2.2,{time:2.2, ease:Linear.easeNone}),'start+=2.2')
.add(TweenMax.to(anim,7,{time:3, ease:Linear.easeNone}),'start+=4.3999999')

You get the problem you report and that is a good ol' overwrite problem and probably the reason why when you change your code to 4.401 it works because maybe you have a delay or something in another part of your code that causes the problem when the second tween of the timeline is added 4.4 seconds after the label. I also changed time for progress and get the same results, like this:

tl.addLabel('start','+=1')
.add(TweenMax.to(anim,2.2,{progress:0.55, ease:Linear.easeNone}),'start+=2.2')
.add(TweenMax.to(anim,7,{progress:0.75, ease:Linear.easeNone}),'start+=4.3999999')

A good exercise would be to get the duration of the timeline and see if it matches with the theoretical time.

 

Also a question, is completely necessary to put the tweens relative to the label?; is there any chance to use just relative positioning based on the timeline's total time like this?:

tl
.add(TweenMax.to(anim,2.2,{time:2.2, ease:Linear.easeNone}),'+=3.2')
.add(TweenMax.to(anim,7,{time:3, ease:Linear.easeNone}));

I get the same behaviour just adding one more second to the first TweenMax instance and setting it's position 3.2 seconds after the beginning, also you could achieve the same with just absolute positioning, like this:

tl
.add(TweenMax.to(anim,2.2,{time:2.2, ease:Linear.easeNone}),3.2)
.add(TweenMax.to(anim,7,{time:3, ease:Linear.easeNone}));

Hope this helps,

Cheers,

Rodrigo.

  • Like 2
Link to post
Share on other sites

Yeah, the overwrite seems to be causing the problem. You seem to have a good grasp on that, thanks for looking. The labels are necessary due to nested timelines and positioning, and adding that little bit extra delay solved my problem and my animation looks great.

 

But I didn't really post this to find a solution for myself, as my patch works well enough. Using a label guarantees my tweens are starting from the same timeline insertion point. Look at my original code above, not the codepen, and you can easily see there's no overlap, but yet this code in my script is causing the overlap. Seeing the label creation shows you that there isn't another part of the code affecting the timing, so it shouldn't have that problem.

 

I made this post because it suggests a bug in the gsap code, likely a rounding error since it's not always happening

Link to post
Share on other sites

Since I couldn't reproduce it, i'm just throwing it out there, hoping that someone with an understanding of the gsap code might find a bug and improve the product

Link to post
Share on other sites

Yeah, it's pretty tough to diagnose without seeing it reproduced somehow/somewhere. It does sound like there must be something else going on in your code that's causing the overlap. I suppose it's possible there's some kind of rounding error in GSAP, but I have literally never even once ran into that sort of thing (at least not that I can remember), nor can I remember anyone reporting something like that. Plus I make allowances for rounding issues in the overwrite logic, so I'm relatively confident there isn't a bug but I've seen enough bugs in my time to convince me that it's certainly possible that one is hiding in there. If you're able to send us over a relatively simple example that reproduces things, we'll do our best to take a peek and see what's happening. Glad you got your stuff patched up with that little fix in the mean time, though. 

Link to post
Share on other sites

Hmm I guess I can see where a floating point rounding error might occur when calculating the relative time (e.g. 2.2 + 4.4 = 6.6000000000000005 in javascript), but GSAP is using an epsilon value when comparing times so that difference should be accounted for (and is backed up by us being unable to reproduce the problem...).

 

What version of GSAP are you using in your own application? Maybe there was a really early version of GSAP that didn't have as much protection against floating point errors?

  • Like 2
Link to post
Share on other sites

Newest version.

 

I mean, I could package up my whole scripts, but who would want to go through 70k of uncommented code? Lol

 

It's rather inexplicable to me, since I created the codepen identically. I'm not sure what I would add to reproduce the problem. The graphics? The rest of the tweens in the animation sequence? That would mean rewriting it with hard values, or adding all the overhead code to create the objects.

 

If I get bored, i'll b back it all up and start stripping code out until I find what makes the problem go away, which might be the only way to find this one. Until then, I got everything working smooth, so I'm happy. Thanks guys

Link to post
Share on other sites

Would you mind just trying the attached version of TweenLite in your problematic set of files and letting us know if it resolves things? I just reduced the precision of the padding that gets used for the rounding for overwrite timing comparisons. I kinda doubt it'll act any different for you, but if it does I'd love to hear about it. 

TweenLite.js.zip

  • Like 2
Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×