Jump to content
Search Community

OSUblake last won the day on September 16 2023

OSUblake had the most liked content!

OSUblake

Moderators
  • Posts

    9,196
  • Joined

  • Last visited

  • Days Won

    708

Posts posted by OSUblake

  1. The calculations will be wrong with relative. The modifiers wraps based on the translated X position, but with relative, you would also have to take into account how far left the item is initially positioned.

     

    BTW... this thread has a helper function that may be of use.

     

     

     

    • Like 1
  2. For one, you're using relative values like "-=200" and "+=200". That's just going to add/subtract to whatever the x value is at that moment in time.

     

    For example, if x is 135 when you click prev, then it's going to animate x to 335, and not 400 like you're expecting.

     

    Another thing is that this calculation doesn't work like you might expect when x is negative.

    parseFloat(x) % containerWidth

     

    https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Remainder

     

    Quote

    To obtain a modulo in JavaScript, in place of a % n, use ((a % n ) + n ) % n

     

    Or you can use the wrap util.

    https://greensock.com/docs/v3/GSAP/UtilityMethods/wrap()

     

     

    • Like 1
  3. 19 hours ago, VoicesFromTheFuselage said:

    Thanks OSUblake, seems like ive targeted the pie i cannot bite :)

     

    How far did you get? That's a super complicated animation, and needs to be broken down into pieces. That's why I would recommend starting with the FLIP part.

     

    • Like 2
  4. Oh, I just did a quick estimate to get it working... and I probably used "vh" by accident. Either way, using vh/vw units probably isn't ideal because the gap between the slides looks like a px value.

     

    You would probably have to calculate the amount on every resize. Assuming your component is the entire width of the screen, you could get the bounding rect of the last slide and subtract the screen width from it to get how far the slides need to animate.

     

    const { left, width } = lastSlide.getBoundingClientRect();
    const totalWidth = (left + width);
    const screenWidth = window.innerWidth;
    
    this.galleryAnim.progress(0);
    
    // create new animation
    this.galleryAnim = gsap.to(...)

     

  5. 25 minutes ago, Parthiban said:

    I have about 100 frames in this animation; essentially, there are 100 http requests for loading this experience. I was wondering if it is a good idea to make image sprites and load a single image file;

     

    Loading one image should be faster than loading 100 images, but we're in an http2 world, so the difference is negligible. 

     

    This is my performance tip.... get your animation working first. If you notice a performance problem, I will personally help you fix it.

     

    • Like 1
  6. Cool! I'll update your pen in a few. 

     

    While you're waiting, here is the strategy I use for stuff like that. I use a "hidden" proxy element for the draggable, then apply the changes from that proxy element to something else, like a WebGL animation.

     

    Just an example. Uses are very old version of Angular.

     

    See the Pen 5f0a77404087e565567cfb3870f0c2b6 by osublake (@osublake) on CodePen

     

     

     

     

    • Like 2
  7. 5 hours ago, MFDes said:

    The issue is, it makes it almost impossible for me to add a stagger effect like in this example 

     

    How so? Just animate 3 different shapes. A stagger is just a delay, or you can use different speeds, i.e. durations.

×
×
  • Create New...