Seamless infinite loop using Stagger, first image visible

[gabriel.ortiz]

As an exercise I've been attempting to modify this tween that creates an infinite loop of images fading in with the first image showing on initial render and then will animate out after a delay. The change I'm trying to make is I want to translate AND fade images in while overlapping the previous image.

The sequence I'm looking for is:

• After initial delay on first image
  • Move old image up AND out
  •  right after starting to move the new image up and in on top of the previous image
• Rinse and repeat

 

I'm having trouble with the timing of the stagger. I'm wondering if a label between the first and the last tween segment would help.  I'm also struggling with overlapping image 1 over image 3 when the loop starts all over again. I'm sure adding a z-index somewhere would help but I don't know where.

 

I think I could do a lot of cool stuff if I can master this pattern. In many ways this expected behavior is very similar to @Carl 's stagger example in the "GSAP: Beyond the Basic course"  Greensock Staggers with Seamless Loops but The only difference I'm trying to merge the logic to have the first item visible on load and starts animating after a delay. Any help would be so so appreciated

 

 

See the Pen XWEzNLQ by gortiz022 (@gortiz022) on CodePen

[Carl]

I'm not really following everything that you are asking. I'm a bit confused by some of your code so I'm just starting off with a modification of my tutorial demo

 

See the Pen vYRWmZY?editors=0010 by snorkltv (@snorkltv) on CodePen

 

What is going on here is that the first image is paused at a time of 1 second for 1 second using these 2 lines of code

 

//duration is the amount of time for each images animation.
//by using pause(duration) we pause exactly at the time the first image is done fading in.
animation.pause(duration)
//wait 1 second and then tell the animation to play
gsap.delayedCall(1, ()=>animation.play())

the animation is as follows: "existing image moves up and fades out while next image moves up and fades in"

I'm not sure how this animation differs from what you described. feel free to play with the code or clarify what you would like to be different.

 

[gabriel.ortiz]

Thanks @Carl this is a stroke of genius!

 

Sorry for the confusion in my description. Basically what i'm looking to do is very close to this example (in fact i already have a use-case for it). The only difference in my code example is I'm trying to overlap the incoming image on top of the outgoing image. (Gosh i can see how what i was describing was super weird and confusing)

 

PS I really appreciate you taking the time to lend a hand... 

 

[Carl]

the example I'm using was built specifically for instances when the in and out animations would happen simultaneously and there was no concern for zIndex stacking.

 

I modified it in a way I wouldn't necessarily recommend. To deal with the images moving out slightly after the new image come in I used a customEase to add the appearance of a delay. the CustomEase looks like this. You'll notice the curve is flat at the beginning showing no change in values. I'm not sure this is entirely necessary... but I couldn't figure out a way to adjust the staggers without things going terribly out of synch.

 

To change the zIndex of each new image as it comes in I used a brute-force approach which injects 10,000 sets into the timeline at the proper interval. Again, not something I'd recommend every day. 

 

See the Pen dymZRWO?editors=0010 by snorkltv (@snorkltv) on CodePen

 

The stagger approach I'm using doesn't account for adding callbacks that have access to the index of each element.

 

Starting fresh on this I would use 1 of three methods

 

1: easiest. Just duplicate the first image in the dom and place it after the last image. when the "fake" first image is animation is done animating in and the previous image is fully transitioned out, just jump back to the beginning of the timeline where the real first image is fully visible. You can place a label there to make it easier. 

 

2: ditch the staggers and build the timeline using a loop. this might add some more flexibility for having tweens that have callbacks that change the zIndex sorting. 

 

3: Ditch the timeline completely and use a function-based approach. At certain intervals functions will be called that handle the in and out animations completely independently. This allows transitions to start at different times and overlap however you like. These functions could also ensure the image coming in has the proper zIndex. If you are a creative coding club student I have a 3 part series called "Breaking free of the timeline mindset" that goes over this in depth. 

 

Again, the solution above isn't the best.  hopefully some of this helps. I would very seriously consider going with option 1. there is nothing wrong with duplicating the image if you really want this effect.

 

 

[GreenSock]

2 hours ago, Carl said:

To change the zIndex of each new image as it comes in I used a brute-force approach which injects 10,000 sets into the timeline at the proper interval. Again, not something I'd recommend every day. 

Perhaps just put the zIndex into the tweens so that it starts out at 100 for whichever one is animating in, then it goes to 50 in the middle, and to 0 when it's done fading out (arbitrary values I chose - the important thing is that they're ordered). Definitely no need to use 10,000 set() calls

 

Also, I didn't quite see why there was a need for the CustomEase - couldn't you adjust the insertion point for the out animations? I may be missing something. If so, I apologize. Here's a fork with my attempt:

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

 

Is that the effect you're going for? 

[Carl]

ha. i tried something with adjusting the position parameter but things got all weird. in my haste i just put on a jet pack down the wrong rabbit hole. lol.

 

tweening the zIndex is neat approach. definitely wouldn't have thought of that. thanks for the help and sanity. i knew i was missing something obvious.

[gabriel.ortiz]

Thank you this is brilliant @Carl and @GreenSock ! I never thought about tweening the z-index. I really like the approach of staggering two separate tweens. I think I have a good understanding of how it works.

 

16 hours ago, Carl said:

: ditch the staggers and build the timeline using a loop. this might add some more flexibility for having tweens that have callbacks that change the zIndex sorting. 

As a general principle, when would you consider building an animation using a loop over trying to use staggering? The challenge i initially had with staggering if figuring out the sequencing was tricky to conceptualize.

[GreenSock]

2 hours ago, gabriel.ortiz said:

As a general principle, when would you consider building an animation using a loop over trying to use staggering? The challenge i initially had with staggering if figuring out the sequencing was tricky to conceptualize.

For me personally, it's all about using whichever approach makes the most intuitive sense in YOUR head. GSAP gives you a lot of ways you can accomplish things - there's not one "right" way. If a loop makes more sense in your head, go for it. 👍