Seamless infinite moving objects with ScrollTrigger, velocity, and fading

[SammyC123]

I've managed to wrangle my example to almost precisely how I want it... I'm just stuck on a couple (hopefully) minor details. I have a ScrollTrigger pinned section in the middle, and it has a bunch of circles within it that slowly rise to the top at varying speeds. I'm using velocity to increase that speed when the user scrolls (thanks to some stellar examples on the forums).

 

My issues:

1. I want the circles section to seamlessly wrap by creating new circles that are always coming up from the bottom. Right now I'm using repeat: -1 after 60 seconds, but that is a subpar experience as the circles typically run out before that timer AND the redraw is jarring. I know this is not ideal.
2. I'm cheating to create my fade out/fade in effect at the top and bottom, respectively. Those are just gradient divs. I'd like to actually have the circles fade in and out appropriately near the edges.

Both of these problems seem solvable with something like Blake's SVG clouds experiment: 

See the Pen wWXRQN?editors=0010 by osublake (@osublake) on CodePen

...but I am having trouble understanding how to integrate what he did into my code, particularly with regard to ScrollTrigger.

 

On a final note (more of a tangent), would you recommend redoing this in canvas with arcs for the circles instead? I don't particularly like how much computational power this seems to take, but I'm uncertain if the performance benefit of canvas would reasonably offset the increase in complexity.

 

Thanks for reading, and for any assistance, tips, thoughts, or recommendations.

 

See the Pen PoKmQeL by JC5 (@JC5) on CodePen

[GreenSock]

3 hours ago, SammyC123 said:

• I want the circles section to seamlessly wrap by creating new circles that are always coming up from the bottom. Right now I'm using repeat: -1 after 60 seconds, but that is a subpar experience as the circles typically run out before that timer AND the redraw is jarring. I know this is not ideal.

If I were doing this, I'd probably use a simple function to create a randomized infinitely repeating tween (duration, position) that gets plugged into a timeline and then simply alter the timeScale() of the timeline to make your stuff speed up or slow down. I think that'd be a lot less CPU usage than what you're currently doing with using a modifier on every single element and an onUpdate that's creating a whole new tween every update (don't forget to overwrite: true so you don't end up with a bunch of animations trying to control the same thing). 

 

3 hours ago, SammyC123 said:

1. I'm cheating to create my fade out/fade in effect at the top and bottom, respectively. Those are just gradient divs. I'd like to actually have the circles fade in and out appropriately near the edges.

Honestly, I think that's exactly what I'd do. It's not "cheating" - it's a clever problem-solving technique that saves you from having to calculate all those opacity tweens. Is there some reason you don't want to use the current technique? 

 

3 hours ago, SammyC123 said:

would you recommend redoing this in canvas with arcs for the circles instead? I don't particularly like how much computational power this seems to take, but I'm uncertain if the performance benefit of canvas would reasonably offset the increase in complexity.

Yes, in my experience <canvas> (especially if it's WebGL-enabled) can render much faster than SVG. 

 

Good luck!

[SammyC123]

6 hours ago, GreenSock said:

If I were doing this, I'd probably use a simple function to create a randomized infinitely repeating tween (duration, position) that gets plugged into a timeline and then simply alter the timeScale() of the timeline to make your stuff speed up or slow down. I think that'd be a lot less CPU usage than what you're currently doing with using a modifier on every single element and an onUpdate that's creating a whole new tween every update (don't forget to overwrite: true so you don't end up with a bunch of animations trying to control the same thing). 

That's an interesting approach! Would it be something vaguely like this?

 

See the Pen qBXjXVB by JC5 (@JC5) on CodePen

If so, how would I go about making it so the acceleration only occurs during user scroll, and then how would I get GSAP to tween the timeScale value back to the default of 1 when they've finished?

 

6 hours ago, GreenSock said:

Honestly, I think that's exactly what I'd do. It's not "cheating" - it's a clever problem-solving technique that saves you from having to calculate all those opacity tweens. Is there some reason you don't want to use the current technique? 

That's a fair point. My main concern was with the color banding that occurs from CSS gradients, but I'm sure I can figure a way around that. I'll stick with it for now.

 

6 hours ago, GreenSock said:

Yes, in my experience <canvas> (especially if it's WebGL-enabled) can render much faster than SVG. 

Dang it, I suspected as much. I probably should've started with that. Oh well, maybe after I've perfected this version, I can move on to bigger and better things. I feel like I still have a ton to learn before then though.

 

Thanks for the help, Jack!

[OSUblake]

21 minutes ago, SammyC123 said:

If so, how would I go about making it so the acceleration only occurs during user scroll, and then how would I get GSAP to tween the timeScale value back to the default of 1 when they've finished?

 

You can animate the timeScale of an animation...

gsap.to(tl, {
  overwrite: true,
  timeScale: 1
})

 

For ideas on velocity scrolling, this demo might be a good one to learn from.

 

See the Pen eYpGLYL by GreenSock (@GreenSock) on CodePen

 

[SammyC123]

1 hour ago, OSUblake said:

You can animate the timeScale of an animation...

gsap.to(tl, {
  overwrite: true,
  timeScale: 1
})

Oh my god, that's so frigging cool. (And simple, and elegant.)

 

Jack was spot on. This is a vastly superior way to achieve it.

 

1 hour ago, OSUblake said:

For ideas on velocity scrolling, this demo might be a good one to learn from.

If I wasn't able to see the code, I would have just assumed it was WebGL for that skewing effect. That's such a good demo for so many reasons. Thank you for that. It's yet another for my GSAP bookmarks folder.