Jump to content
Search Community

nesting of staggered timelines creates quantum leaps, no intermediate timestamps, clumping of previously staggered tweens

ripmurdock test
Moderator Tag

Recommended Posts

Hi,

I’m attempting to write an animation that runs in randomly generated lengths forward and backwards with an ease applied to each segment.

The sequence of child timelines appears to breakdown at parent timeline durations of less than 2 seconds with power4.inOut and also breaks down with no ease applied to the parent timeline at durations of less than 0.5 seconds.

The child timeline applies conditional logic to toggle the visibility of the targets in alternating fashion, so the order in which the functions are executed is critical, while the time between firings is not.

At shorter parent timeline durations, tweens that are staggered in the child timeline sometimes all end up with the same timestamp leaving no tween executed at the intervals at which those tweens should have fired.

The times at which the staggered tweens are executed appear to be quantum states with no intermediate values, with or without an ease applied to the parent timeline.

With a parent timeline duration of 2 and ease of power4.inOut, toggling visibility is still correctly alternated on the 4th repeat, for example with item 7 being made visible immediately before item 6 is hidden.

 

image.png.b1376ef36b95b2228e23f3d781652d09.png

With a parent timeline duration of 1.2 and ease of power4.inOut, tweens which should be staggered are executed at the same timestamp with none executed at intermediate values or at the vacated timestamp positions.

Here the tweens that should have been executed with timestamps of approximately 7, 8, and 9 are all executed with a timestamp of approximately 9 for both series, so that instead of tweens alternating toggling at 7, 8, and 9 timestamps, six tweens are executed with timestamp around 9, with all three from the first series executed before all three from the second series:

image.png.d2113acfcf621295b85ec82d02f2f14b.png

Changing the stagger times for the child timelines doesn’t appear to alter the tendency of staggered tweens to be clumped together.  Clumping of staggered tweens also begins happening with no parent timeline ease at parent timeline durations of 0.5 seconds or less.

Is there any way to get a series of staggered tweens to execute at intermediate timestamps when nested in a parent timeline without tweens making quantum leaps to a different tween’s timestamp?

Or is there a more efficient way to execute an accordion-like in and out animation of discrete images running at random lengths in each direction with an ease applied to each segment?

Thanks!

See the Pen GRyzGog by ripmurdock (@ripmurdock) on CodePen

Link to comment
Share on other sites

I'm having a hard time following your question and demo, but I think you just want the aperture animation to play/reverse at various durations and delays. If so, you can create the staggered timeline with the 12 paths and then tween the progress of that timeline forwards and backwards like this.

 

See the Pen bGaZpVp by PointC (@PointC) on CodePen

 

Hopefully that helps. Happy tweening.

  • Like 1
Link to comment
Share on other sites

Thanks!  This is a more elegant solution than mine.  I spent a lot of time figuring out the triggers in each direction that would allow the animation to start from any visible image.

 

I'm still interested in understanding how GSAP executes staggered functions.  Going forward should I assume that if a staggered timeline is nested, the intervals could range anywhere from 0x to 3x the average interval, so that if two timelines are executing identical functions on identical targets, one might execute the function for item #9 before the other executes the function for item #7?  I expected the parent timeline to expand and contract the intervals in the child timeline, but apparently the intervals can't have any intermediate values, so GSAP expands and contracts the intervals by grouping tweens together on alternate intervals and doesn't allow other tweens that would fire during those intervals to fire until after the multiple tweens grouped together on a singe staggered interval fire.

 

In the example above the tweens from the two series alternate about 1 second timestamp apart, and all of a sudden two intervals are skipped, and six timelines are executed at the 9.177432 timestamp, which would be fine if the order in which they are executed wasn't scrambled.  In this case the series of tweens that starts one stagger interval ahead of the other series executes it's tween on items 7, 8, and 9 and the second series subsequently executes it's tweens on items 6, 7, and 8.

 

Is there any way to predict the order in which staggered tweens will be executed if they are nested?

 

I'll look to integrate your solution with my current project.  Thanks again!

Link to comment
Share on other sites

1 hour ago, ripmurdock said:

I'm still interested in understanding how GSAP executes staggered functions.  Going forward should I assume that if a staggered timeline is nested, the intervals could range anywhere from 0x to 3x the average interval, so that if two timelines are executing identical functions on identical targets, one might execute the function for item #9 before the other executes the function for item #7?  I expected the parent timeline to expand and contract the intervals in the child timeline, but apparently the intervals can't have any intermediate values, so GSAP expands and contracts the intervals by grouping tweens together on alternate intervals and doesn't allow other tweens that would fire during those intervals to fire until after the multiple tweens grouped together on a singe staggered interval fire.

 

In the example above the tweens from the two series alternate about 1 second timestamp apart, and all of a sudden two intervals are skipped, and six timelines are executed at the 9.177432 timestamp, which would be fine if the order in which they are executed wasn't scrambled.  In this case the series of tweens that starts one stagger interval ahead of the other series executes it's tween on items 7, 8, and 9 and the second series subsequently executes it's tweens on items 6, 7, and 8.

 

I'm having a really hard time understanding you but none of this sounds correct to me (and I authored the platform). GSAP doesn't scramble anything, nor does it expand or contract intervals or do something on alternate intervals with intermediate values, etc. It's actually quite simple: 

 

You can place child animations on a parent timeline. You can nest them as deeply as you want. As a parent timeline's playhead updates, it updates the child animations' playheads so that they're always synchronized. When you do a stagger, all that's doing is placing those child animations on the timeline accordingly. That's it. The system is very flexible, yet simple at its core. 

 

So a stagger: 0.2 means the first child will have a startTime of 0, the next 0.2, then the next one 0.4, etc. 

 

Keep in mind that the browser renders roughly ever 0.1667ms, thus updates will happen around that time but it totally depends on the browser and how much load it's under.

 

It may clear things up if you read this: https://greensock.com/docs/v3/GSAP

 

If you're still struggling with something, please provide the most minimal possible demo that you can which illustrates the problem. Again, please strip everything out and only include what you absolutely must in order to make the problem clear and concise (hopefully not paragraphs of text to read too...it's easy to get lost), and we'd be happy to answer any GSAP-specific questions. 

Link to comment
Share on other sites

Thanks for your help.

 

Here's a scaled down example that demonstrates the quantum leap phenomenon.

See the Pen bGaZBee by ripmurdock (@ripmurdock) on CodePen

 

With shorter code I didn't see any quantum leaps until the parent timeline duration was shortened to 1 second or less.  Even with no ease on the parent timeline and less code, the phenomenon is common at 0.5 seconds or less.

 

I added labels to the variables in the console log to make it easier to follow.  The child timeline is constructed with two staggered series of tweens on the same elements with the tweens in the second series entered into the timeline at a position offset equal to the stagger interval, so that the child timeline consists of series of functions at these positions item 1 function 1 . . . item 2 function 1 / item 1 function 2 . . .  item 3 function 1 / item 2 function 2  . . .

 

The timestamps are in the child timeline interval units.  I set the stagger interval to 1 second.

 

At larger durations for the parent timeline, the functions are executed in the expected order, at approximately 1 second intervals with the first declared tween executed ahead of the second declared tween for ties:

image.thumb.png.8ffff2dcd7dad65741b9aab06e5f1ffc.png

 

At smaller parent timeline durations, tweens make quantum jumps to other tween's intervals, like this:

image.thumb.png.892f2a0555a5d797d9a788a32b73af94.png

 

In this example, no tweens are executed at the 4th (3 second) interval, the 6th (5 second interval) , the 8th (7 second interval), or the 9th (8 second interval), and no tweens are executed at any intermediate intervals.

 

When GSAP catches up, the tweens are not executed in the order in which their positions are defined on the timeline.  Instead, all of the function 1 tweens are executed, and then all of the function 2 tweens are executed.  Based on the positions defined in the timeline, it should be impossible for the tween representing function 1 on item 9 to be executed before function 2 is executed on either item 6 or 7.

 

I'd be curious if there's any way to strictly enforce the position order defined in the timeline when deploying staggered tweens in nested child timelines.

 

Or perhaps there are some limits of which I should be aware when deploying staggered tweens or tweens constructed with functions.

 

Thanks again.

Link to comment
Share on other sites

Sorry, @ripmurdock, perhaps my brain is just foggy at the moment but I find your demos to be extremely convoluted and difficult to follow. We really just need the most minimal demo possible. A few colored divs and straightforward timeline construction. Not complex nested functions looping 7 times creating more nested timelines 4-levels deep with function-based variables that only console things when one counter variable matches a different one, tweens of the progress of other paused timelines nested inside infinitely repeating timelines with delays inbetween, hard to decipher strings like ".FD_vis0-12_hat_cl-12", etc.

 

I'm pretty sure this is just a misunderstanding on your part or a logic flaw in your code, but I don't have time to wrap my head around all the winding trails in there right now.

 

Keep in mind that when a timeline updates, it pulses that update down through all its children in order. For example, if child1 updates which updates all its children, then child2 with all its children, etc. Clean encapsulation. Perhaps you expected it to search all children, nested ones inside of those, etc. and then update them in the global order they appear? That would be terrible for performance, impractical, and almost never needed anyway. Plus it would break callback order and other things. 

 

If you still need help, please provide a clearer, simpler, more straightforward demo that illustrates the problem and we'd be glad to take a peek. 

  • Like 1
Link to comment
Share on other sites

Thanks.  I’m looking to integrate your randomized progress solution with the rest of my animation.  I added a randomized number of repeats, but I couldn’t figure out how to randomize the return point for all but the last return or how to randomize the duration of the return:

See the Pen YzYgVgX by ripmurdock (@ripmurdock) on CodePen

I’d like the sequence to start from aperture.progress(0) and end on aperture.progress(0), with each of the intermediate reversal points and the duration in both directions randomized with an ease applied.

 

Please let me know if the randomized progress solution can be revised such that the aperture animation doesn’t return to aperture.progress(0) after each call and the duration is random on the forward and reverse motion.

Thanks for your help.

Link to comment
Share on other sites

1 hour ago, ripmurdock said:

Please let me know if the randomized progress solution can be revised such that the aperture animation doesn’t return to aperture.progress(0) after each call

My original answer demo uses a yoyo tween to go back to progress(0) each time. If you don't want that, you can remove the yoyo and the repeatDelay and instead choose a random progress on each iteration.

 

When you're done with your loop of random animations you can add a stand-alone tween to tween the progress back to zero.

  • Like 1
Link to comment
Share on other sites

Thanks.  I couldn’t figure out if there’s a way to use progress to sample the right hand side of a timeline, but I was able to get the two sided animation I was looking for by tweening the time property backward and forward and keeping track of the last reversal point:

See the Pen PoELgvv by ripmurdock (@ripmurdock) on CodePen

 

Separating the logic that alternates the image properties from the logic that determines the animation reversal points removed the functions from the to statements.

I’d be curious why my original solution didn’t work.  Timelines with function determined values is one of the features of GSAP that I’m most interested in exploring.

Here’s a simplified version of the sequence above with more descriptive variable names. 

See the Pen wvpOeKr?editors=0011 by ripmurdock (@ripmurdock) on CodePen

It has one child timeline and one parent timeline.  In the real version I have the whole sequence repeated 3 to 7 times, but I just entered 7 here.  After the sequence is completed, the animation resets to image_12.

The original child timeline uses the same structure to ensure that exactly one image in the series is visible at all times, although the logic determining the reversal point was contained in the to function.

Feel free to enter any value 1-7 for t1counter_for_console to see the timestamps for when the function for each tween is fired on that iteration.  The console only executes the log statement the first time the statement is run, so you can only monitor one iteration at a time.

Also, feel free to enter any value for parent_timeline_duration. 

On my end the logs show the tween functions alternating as expected for 2+ second parent tweens and batches of intervals being skipped and the functions not alternating for parent tweens 2 seconds or less for the longer code and 1 second of less for the shorter code.

 

I'd be curious if there's a limit to how many statements can be included in a 'to' function over a given duration before the statements begin to be executed in the wrong order, like this:

image.thumb.png.f0c5543256b4bc6ec855543a688b2ddf.png

Thanks for your help. 

image.png

Link to comment
Share on other sites

1 hour ago, ripmurdock said:

I'd be curious if there's a limit to how many statements can be included in a 'to' function over a given duration before the statements begin to be executed in the wrong order, like this:

 

No, there are no limits whatsoever. Again, I think this has to do with a misunderstanding on your part. I'm traveling at the moment, so I can't spend the time to wrap my head around everything you're doing in that demo, what your expectations are, parse through your paragraphs of descriptive text, etc. But again, there are no limits on the quantity of tweens or sub-timelines, etc. It's all very modularized and clean in terms of how things get updated. I'd encourage you to re-read my description in my last reply about how things are updated (parent updates pulse down through the children). Perhaps that'll make things fall into place for you. 

 

GSAP is used on over 11 million sites and some of the most demanding, creative developers out there and I don't recall anyone else bringing up an issue like you're describing so that's why I suspect there's just a misunderstanding lurking somewhere here. I wish I had more time to devote to this right now but it has been super difficult for me to understand your demos and descriptions. I asked that you provide a very minimal demo with just some colored <div> elements and the most straightforward Timeline/animation construction but it looks like you used basically the same demo with a few tweaks, so it'll likely require more time to dig into once I'm back from travels. Obviously if there are any bugs/issues in GSAP we'll definitely want to resolve those ASAP. But again, I think it's a misunderstanding. 

  • Like 2
Link to comment
Share on other sites

Thanks for taking a look at this.

 

In this simplified version I've replaced the conditional logic and references to element properties with a simple counting loop.

See the Pen PoErvoa?editors=0011 by ripmurdock (@ripmurdock) on CodePen

 

For a 0.5 second duration the sequence completes and correctly alternates the two functions for a count to 100,000, but consistently skips stagger intervals, and then executes the functions in the wrong order for a count to 1,000,000.

 

The original test didn't have any loops, but it did have conditional logic and element property returns.

 

Is there any way to know what I can put in a function inside a tween before the functions begin to be executed in the wrong order?

 

Thanks again.

 

 

 

 

Link to comment
Share on other sites

Hi ripmurdock,

 

I've read your posts several times, and I'm very confused about what you're asking or having problems with. It's not clicking for me what those console log statements are supposed to mean, or why they're wrong. What are you expecting to happen in the demo above and what do you think should be the correct behavior?

Link to comment
Share on other sites

Thanks.

 

A child timeline constructed with two staggered tweens over the same array of items 0-n with the second tween delayed by the stagger value like this:

 

const aperture = gsap.timeline({ paused: true });

aperture.set(targets, { autoAlpha: 1, stagger: stagger });

aperture.set(targets, { autoAlpha: 0, stagger: stagger }, stagger);

 

defines alternating positions for the first and second tween over the array like this:

 

item 0 1st tween

 

item 1 1st tween

item 0 2nd tween

 

item 2 1st tween

item 1 2nd tween

 

. . .

 

item n 1st tween

item (n-1) 2nd tween

 

item n 2nd tween

 

I would expect the order of this sequence to be preserved also if the value of one or more of the properties in the tween is determined by a function.

 

The timestamp logs show that as the complexity of a function contained in the tween increases or the duration of the parent tween decreases, the order in which the functions are executed deviates from this order and that the deviation varies directly with function complexity and inversely with parent tween duration.  The 1st tween is executed for a batch of items, followed by the 2nd tween being executed for a batch of items, instead of each tween being executed for a single item in alternating fashion.

 

Interestingly, the timestamp logs also show that when the alternation breaks down, one or more stagger intervals are skipped and that no tweens are executed at any timestamps with intermediate values.

 

The timestamp logs look like this:

 

item 6 1st tween

item 7 1st tween

item 8 1st tween

item 9 1st tween

 

item 5 2nd tween

item 6 2nd tween

item 7 2nd tween

item 8 2nd tween

 

It looks like there is some limit to how complex a function contained in a tween can be for a given timeline duration.

 

For my purposes, I would like to have a way to maintain the position of the tweens on the timeline no matter how complex the tween functions are.

 

Alternatively, I would like to understand how complex a tween function can be for a given duration before the position of the tweens on the timeline is scrambled, so that I don’t have to create timestamp logs and run tests to make sure my functions are not too complex.

 

Thanks for your help.

Link to comment
Share on other sites

There's no "scrambling" and as far as I can tell it's working exactly the way it should. Your demo is still much more complicated than it needs to be - here's a simpler demo that will hopefully clarify things: 

See the Pen PoEMRKY?editors=0010 by GreenSock (@GreenSock) on CodePen

 

If you want every set/tween call to act independently and be updated in the same context, don't nest things - use a simple loop: 

See the Pen xxpvWYJ?editors=0010 by GreenSock (@GreenSock) on CodePen

 

Again, it's not a bug nor is it scrambling things - it is simply updating each animation appropriately and sequentially, including its children.

 

Let's say tween1 has very tightly-spaced sub-tweens (stagger: 0.001) and tween2 has the same tight pattern (stagger: 0.001). If 0.0167 seconds elapses (typical), it updates the parent playhead which updates each child in order, so tween1 would update which would also update all of IT'S children and in this case that means 16 of those sub-tweens. Then it updates tween2's playhead and its children, thus 16 of those. So you'd see a group of the children from tween1 update and a group of children from tween2 update. That's what I explained initially to you. 

 

To complicate things, you're using function-based values that are taking a very long time to process due to your code inside those functions, thus there's a much longer gap until the next tick, so the first update may be at 0.0167 seconds but the next one may not fire until 0.08 seconds later which means there will be and even larger batch of tweens updating at that point. 

 

Do you understand now? 

  • Like 1
Link to comment
Share on other sites

Thanks.

 

Also for this simplified version with only three elements, on my end I'm seeing tweens executed in the wrong order.  The breaking point appears to be 0.6 seconds for these functions.

 

The t1 timeline defines alternating positions of the tweens, which is what the timestamps show for a duration of 1 second:

image.thumb.png.0f12f8994dfc81ddb5151143641d22ca.png

 

Even with only 3 elements, the order in which the tweens are executed is scrambled at 0.6 seconds.  According to the definition of t1, the "set 250 (1st)" tween cannot be executed on index 2 before the "set 500 (2nd)" tween is executed on index 0.  On my end I'm seeing the 1st tween executed on all of the elements before the 2nd tween is executed on any elements, even though the definition of t1 establishes alternating positions:

 

image.thumb.png.fcc35f43a39677dd396cb1e8c26ea349.png

 

See the Pen WNMeegB?editors=0011 by ripmurdock (@ripmurdock) on CodePen

 

Is there any way to enforce strict adherence to the position order defined in the t1 timeline?

 

Thanks for your help.

Link to comment
Share on other sites

You're trying to animate the progress of a timeline that's already playing, so you're creating conflicts. The timeline is moving its own playhead on each tick and then you're forcing it to a totally different spot with the external tween.

 

I'm also not sure why you set pause: 0 in the vars object of the timeline - that's not valid. Maybe you meant paused: true

 

I already gave you a solution. Did you not see that? Don't nest things if you don't want things to update in groups like that. Do a simple loop and insert things in whatever order you want (flat, not nested). It seems like you may not be fully reading or grasping what I've explained in previous responses. There is no "scrambling" happening at all. It's doing precisely what it's supposed to do. I think you're just misunderstanding how things get updated.

  • Like 2
Link to comment
Share on other sites

Thanks. 

 

This sequence is part of a longer animation.  The parent-child structure was recommended to apply an ease and a random duration to the entire sequence.

 

Does nesting a timeline change the position of the tweens in the child timeline?

 

This animation depends on the tweens being executed always in the same sequence.

 

I corrected the syntax to pause the child tween.  I'm still seeing the 1st tween executed on all of the items before the 2nd tween is executed on any item.

 

Perhaps a child timeline requires the stagger value to be determined by a function to ensure the tweens maintain the same sequence when called by a parent timeline.

Link to comment
Share on other sites

I also tried eliminating the parent timeline and applying a duration directly to the t1 timeline constructed with two staggered tweens.

 

Under this scenario the sequence order is preserved, but duration defined for the timeline is overridden.  The duration is the sum of the staggers intervals over the elements.

 

Perhaps a stagger value determined by a function could ensure the tweens alternate over a shorter duration.

 

Link to comment
Share on other sites

29 minutes ago, ripmurdock said:

Does nesting a timeline change the position of the tweens in the child timeline?

No, not at all. 

 

30 minutes ago, ripmurdock said:

I corrected the syntax to pause the child tween.  I'm still seeing the 1st tween executed on all of the items before the 2nd tween is executed on any item.

If you're having trouble, please provide a minimal demo that clearly shows the issue. You shouldn't be pausing the children - I'm not sure why you thought that would be helpful. Perhaps you meant to pause the parent - the one whose progress you're animating with an external tween? 

 

32 minutes ago, ripmurdock said:

Perhaps a child timeline requires the stagger value to be determined by a function to ensure the tweens maintain the same sequence when called by a parent timeline.

I don't understand why you'd think that would be helpful. 

 

11 minutes ago, ripmurdock said:

I also tried eliminating the parent timeline and applying a duration directly to the t1 timeline constructed with two staggered tweens.

 

Under this scenario the sequence order is preserved, but duration defined for the timeline is overridden.  The duration is the sum of the staggers intervals over the elements.

Again, I don't follow - please make sure you provide a minimal demo that clearly shows the issue if you'd like help. 

 

11 minutes ago, ripmurdock said:

Perhaps a stagger value determined by a function could ensure the tweens alternate over a shorter duration.

Sorry, I have no idea what you mean.

 

I provided a solution already. I'm not sure what exactly you're struggling with, so it'll be helpful to see that minimal demo

  • Like 1
Link to comment
Share on other sites

Maybe this helper function will assist you - it should basically flatten a timeline so you could still build things the way you find it convenient and then feed it to this function: 

function flattenTimeline(tl) {
	let start = tl.globalTime(0),
		children = tl.getChildren(true, true, false),
		data = [];
	children.forEach(tween => tween.timeline ? data.push(...tween.timeline.getChildren()) : data.push(tween))
	data = data.map(tween => { return {time: tween.globalTime(0) - start, tween: tween}; });
	tl.clear();
	data.sort((a, b) => a.time - b.time);
	data.forEach(d => tl.add(d.tween, d.time));
	return tl;
}

Just an idea. I have no idea if it'll actually help in your scenario but I figured I'd offer it anyway. 

Link to comment
Share on other sites

Thanks.  I'll give this a try.

 

Eliminating the parent timeline didn't work because I wasn't able to control the duration and ease for the entire sequence.

 

I paused the child timeline so that it would not already be running when called by the parent timeline.  This structure was recommended to me previously.

 

Here's a minimal example:

See the Pen WNMeegB by ripmurdock (@ripmurdock) on CodePen

 

When the t1 timeline runs on its own, the 1st and 2nd tweens alternate.  When it is called by the parent timeline, the 1st and 2nd tweens no longer alternate.  The 1st tween is executed over all elements, and subsequently the second tween is executed over all of the elements.  The position of the tweens on the parent timeline is different than the position on the child timeline.

 

I'll try the flattenTimeline function.  Thanks again.

 

Link to comment
Share on other sites

3 hours ago, ripmurdock said:

Eliminating the parent timeline didn't work because I wasn't able to control the duration and ease for the entire sequence.

Why not? That should be pretty simple. Create the flattened timeline, pause it, and animate its progress. 

 

3 hours ago, ripmurdock said:

I paused the child timeline so that it would not already be running when called by the parent timeline.  This structure was recommended to me previously.

No, I think you misunderstood - you pause the timeline whose progress you're animating with the external tween. You don't pause the children. 

 

3 hours ago, ripmurdock said:

When the t1 timeline runs on its own, the 1st and 2nd tweens alternate.  When it is called by the parent timeline, the 1st and 2nd tweens no longer alternate.  The 1st tween is executed over all elements, and subsequently the second tween is executed over all of the elements. 

You're still grouping them. And the reason things look different when you're using that parent to tween the progress is that you're shrinking the duration and applying an ease so the ticks line up differently. It's working exactly the way it's supposed to and I've tried to explain 3 times now why it's grouping the updates like that. It is the correct behavior. 

 

It might help if you think about what happens on each tick. Visualize where the playhead would jump each time and what happens when the parent updates child-by-child. For example, if you're scrubbing the playhead on a 1.5-second timeline in only 0.5 seconds, and you have expensive function-based values that make the time between ticks longer, what happens? Let's say the first tick happens 0.0167 seconds in, that would actually map to 0.05 seconds into the scrubbing timeline linearly (since you're squishing a 1.5-second timeline into 0.5 seconds, 3x faster than normal) and then you've got a "power4.inOut" ease applied which would alter that to a lower number at the start. 

 

In any case, the next tick may happen 0.08 seconds later which maps linearly to 0.24 seconds onto the scrubbed timeline which means it must update all the tweens/sets that occur between the last tick and this one. It goes down child-by-child in order and updates them accordingly. So if you bog things down enough, the playhead will jump far enough to need to update several tweens in each sub-animation. 

 

3 hours ago, ripmurdock said:

The position of the tweens on the parent timeline is different than the position on the child timeline.

I don't understand what you mean by this. Please explain and provide a minimal demo. You're probably just talking about the fact that you're squeezing a 1.5-second timeline into 0.5 seconds and also applying an ease that moves the playhead slower at the start/end and much faster in the middle. 

 

I feel like we're wasting a lot of time going back and forth with theoreticals; I've already given you a solution several times and even delivered a helper function to flatten things for you. I'm not sure what else I can do at this point but I do think it would be best for you to create a minimal demo with a very specific goal in mind so that we can just make that work for you. I thought I already did, but maybe I misunderstood your goal. So again, that minimal demo with a crystal clear goal will be key here moving forward. 

Link to comment
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.
×
×
  • Create New...