Jump to content
Search Community

GreenSock last won the day on June 13

GreenSock had the most liked content!

GreenSock

Administrators
  • Posts

    23,244
  • Joined

  • Last visited

  • Days Won

    827

GreenSock last won the day on June 13

GreenSock had the most liked content!

Profile Information

  • Location
    Chicago Area
  • Interests
    Volleyball, Basketball, Christian Apologetics, Motorcycling

Recent Profile Visitors

101,045 profile views

GreenSock's Achievements

  1. Notice you've actually got TWO scrollbars on the right side. This looks like a CSS issue in the way you set it up. Just remove the overflow-x: hidden from the html element. body { /* NOT html, body */ font-family: "Rock Salt", cursive; width: 100%; height: 100%; color: #fff; overflow-x: hidden; } Does that clear things up? Basically, your scroller wasn't what you thought it was.
  2. We intentionally don't mention "linear" because that's the same as "none" which is simpler and more obvious. As for causing your elements to change position, I'm not quite sure wht you mean by that. Can you please explain and also provide a minimal demo like a CodePen? That'd be super helpful.
  3. Isn't that what I already explained in my second reply?: From what I can tell, it's all working perfectly. In order for it to work the way I think you're expecting, it would have to NOT allow the image to move the full distance inside the container, but only sometimes (when the image is adequately tall compared to the container). See what I mean? For example, let's say you've got an image that's only 100px taller than its container, and your viewport is 1000px tall. If the container is 500px, that means the image would move a total of 100px over the course of scrolling 1500px (the top of the container hits the bottom of the screen, then must travel 1000px, the height of the viewport, plus another 500px to get fully out of the viewport). So the image would be moving 0.06667 pixels in the opposite direction of scroll for every 1 pixel of scrolling. But let's say your image is 2500px taller than its container instead of 100px! Now, it must move 2500px over the course of 1500px of scroll. So now, it'd move the image 1.6667 pixels in the opposite direction for every 1 pixel of scroll! Therefore it'll look like it's going FASTER down than the whole page is moving up with scrolling (hence it appears to go backwards). None of that is incorrect behavior. It's precisely what the math would dictate. And by the way, it'd technically move more than what I mentioned above because "auto" attempts to move it all the way across the container, so it'd include that distance too, but I was trying to keep it simpler to visualize. It's the same dynamic at play either way.
  4. Are you just saying that the initial creation seems to take longer than you'd expect? Actual dragging is fine, right? There are definitely calculations that must be done initially to figure out exactly where the bounds must be so that during dragging it's nice and fast.
  5. Yeah, that's because your tween animates ALL of those elements. I assume you meant to do something more like this?: https://codepen.io/GreenSock/pen/eYaeray?editors=0010
  6. Yes, I'm struggling to understand why you think that behavior is incorrect. It's working precisely how I'd expect. 🤔 The image is initially set up such that the extra chunk of the image is bleeding out the top of its container, thus ScrollSmoother does all the necessary calculations to move the image DOWN as the container moves upward through the viewport. Am I missing something?
  7. Unfortunately, we just don’t have the resources to build custom demos for people. I would suggest that you give it a try and then if you get stuck, post your demo here and we will do our best to help. we really tried to keep the questions in these forms GSAP-specific. Maybe somebody else has a demo or is willing to build one for you. I just don’t have time at the moment.
  8. From a quick glance, it looks like that site just uses two identical copies of the text lines on top of each other, and animates the clip-path of each one with an inset() and a CSS "--size" variable (in percent).
  9. Hi @janivibe. I read your question several times and I still don't quite understand what you're asking. Can you please be more clear? That CodePen appears to be working correctly, right? What exactly is the issue?
  10. Hm, perhaps I'm misunderstanding you or I'm not explaining things well, but here's a fork that illustrates a little better: https://codepen.io/GreenSock/pen/xxNPGMx From what I can tell, everything is working perfectly. Notice that in every case, it is indeed moving the image from top to bottom inside the container(s). I think what might be confusing you is that based on the height of the image/container/viewport, they move at different speeds, thus sometimes it's slower than the scrolling speed of the overall page, and other times it's faster, thus they APPEAR to be going in different directions but that's only because of the relative speed of the page scrolling speed. Right?
  11. Hi @ixdf. Thanks for being a Club GSAP member! 💚 I've never heard of anything that can just automatically convert a Lottie animation to GSAP. I don't really think that's feasible, partially because Lottie files contain actual artwork. Perhaps there'd be a way to parse through all the JSON data to only isolate the animation aspects and then delete all of that from the JSON and rebuild it in GSAP commands, but I'm really not sure. I'm curious what is driving your decision to try to keep Lottie artwork and move the animation part to GSAP(?)
  12. Hm, you're locking the top of the video to 100px down from the top of the screen, though, so logically it wouldn't necessarily intersect with the red box when the red box hits the center of the viewport. If you want it to unpin when it's centered vertically in the red, perhaps this is what you're looking for? https://codepen.io/GreenSock/pen/rNgGRNB?editors=1010
  13. Are you trying to do this?: https://codesandbox.io/p/sandbox/funny-bush-forked-gpj8xt?file=%2Findex.js%3A19%2C23 let tween; function moveCharacterFn(endPoint, movingTime) { gsap.registerPlugin(MotionPathPlugin); function createTween() { // save progress before we kill tween if it exists. let start = 0.05; if (tween) { start = tween.vars.motionPath.start + (tween.vars.motionPath.end - tween.vars.motionPath.start) * tween.ratio; tween.kill(); } // create the tween tween = gsap.to(".character", { motionPath: { path: ".path", align: ".path", alignOrigin: [0.8, 0.8], autoRotate: false, start: start, end: endPoint, }, duration: movingTime, repeat: 0, repeatDelay: 1, ease: "power1.inOut", }); } createTween(); // listen for window resize to recalculate tween. window.addEventListener("resize", createTween); }
  14. Sure, it was just this: function positionClipping() { let video = document.querySelector(".bg-video"), bounds = startShape.getBBox(); gsap.set(startShape, { // first, figure out how far it'd take to center the element at 0,0, then offset it by half the width/height of the video x: -(bounds.x + bounds.width / 2) + video.offsetWidth / 2, y: -(bounds.y + bounds.height / 2) + video.offsetHeight / 2 }); } ScrollTrigger.addEventListener("refresh", positionClipping); I made the SVG position: absolute because otherwise it was taking up space in the Flexbox and shoving your video over (off-centered). That basically took it out of the document flow. Sure, you can do whatever you want with the CSS. Maybe I'm not understanding your goal properly. Feel free to give it a try and if you get stuck, post back here with a minimal demo that very clearly illustrates the problem.
  15. Hi @Salumsu. You'd use it just like you would anywhere. There's nothing really special you have to do. If you're running into a problem, just post a minimal demo (like a Stackblitz) that clearly illustrates the problem and we'd be happy to take a peek. Here is a starter template you can fork: https://stackblitz.com/edit/react-cxv92j
×
×
  • Create New...