Smooth Scroller effects on reverse scroll

[celli]

Smooth Scroller is awesome thank you GSAP!

 

Question: I have a set of 6 boxes that form two rows, and since there are two rows of elements I am trying to figure out if there is a way to control the position effects of smooth scroller when we are scrolling back up.

 

When we scroll down it looks perfect, but since we have two rows, when we scroll back up the boxes collide since it is using the first box (top left) as the first box to stagger. On the way back up it might be better to use the bottom right box, or to keep the boxes from overshooting their regular position when scrolling back up, if possible?

 

I was also looking at the ability to use the onUpdate and getVelocity, and I see how we can control and clamp rotation values, but I was looking to see how we can use a similar effect to control opacity based on the position of the elements, not necessarily the velocity—is that possible?
 

See the Pen gOoGqJj by celli (@celli) on CodePen

[OSUblake]

3 hours ago, celli said:

When we scroll down it looks perfect, but since we have two rows, when we scroll back up the boxes collide since it is using the first box (top left) as the first box to stagger. On the way back up it might be better to use the bottom right box, or to keep the boxes from overshooting their regular position when scrolling back up, if possible?

 

Not really. You would have recreate the lag effects once you've scrolled past them, but in reverse order. That could be problematic because you could still switch scroll directions while they are in view, so they would still have the same lag effects.

 

3 hours ago, celli said:

I was also looking at the ability to use the onUpdate and getVelocity, and I see how we can control and clamp rotation values, but I was looking to see how we can use a similar effect to control opacity based on the position of the elements, not necessarily the velocity—is that possible?

 

It'd be a similar approach, but of course you would need to clamp the value between 0 and 1, because you can't have an opacity value outside of that range.

 

[celli]

Thanks for the response. I see your points here!

[PointC]

I was just messing with that while Blake was dropping knowledge and came to the same conclusion. I was using Observer to listen for a toggleY, reversed the array and iterated through adding the new lag. Super weird and awkward especially when all the elements are in view. 

 

Not recommended.

 

[PointC]

I suppose another approach would be to add the same lag to the #1/#4, #2/#5 and #3/#6 elements so they would be laggy columns rather than individual items. That way it would look the same with either scroll direction and they wouldn't bump into each other.

 

Just a thought. YMMV.

 

[GreenSock]

Yeah, what about something like this?: 

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

 

I only allowed there to be 0.1 variance in the speed between ones on top of each other so they don't move in lock-step (I like the fluidity/staggering). 

 

You don't have to do a .forEach() loop either or set speed: 1 - just use a function-based value like this: 

smoother.effects(".box", {
  lag: i => (i % 3) * 0.3 + Math.floor(i / 3) * 0.1
});

 

[celli]

wow, yes, that is awesome how that works! I'd want to turn it off on smaller screens, it doesn't seem to work well on my phone—but yes that works so well.

[Cassie]

Just dropping in to say that animating opacity based on the position of elements sounds like a ScrollTrigger job too. FWIW