Jump to content
GreenSock

Search In
  • More options...
Find results that contain...
Find results in...

GreenSock last won the day on January 17

GreenSock had the most liked content!

GreenSock

Administrators
  • Posts

    18,113
  • Joined

  • Last visited

  • Days Won

    607

GreenSock last won the day on January 17

GreenSock had the most liked content!

About GreenSock

Profile Information

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

Recent Profile Visitors

68,074 profile views

GreenSock's Achievements

  1. That's a very cool effect. I'm not much of a React guy but we do have an article about using GSAP in React: Beyond that, I'd recommend starting simple and building up from there. If you get stuck, post your question here along with a minimal demo and we'd be happy to answer anything that's GSAP/ScrollTrigger-specific. Good luck!
  2. Not really. Even animations with repeat: -1 technically have a start, so if you reverse() it could reach the beginning. Think of repeat: -1 as just having a SUUUUPER long totalDuration. It's not just for the end of an animation - it could be the start too. Like if you're trying to do an infinite repeat in reverse, you might have an onReverseComplete that fires 15ms (or whatever) past the start in reverse in which case rawTime() could be useful. But honestly it's incredibly rare that anyone would need rawTime() in practical real-world scenarios. I'm a little fuzzy on what you're asking here - if you want to know how many seconds it would take for a timeline to do two iterations plus any repeatDelay, sure: let cycle = tl.duration() * 2 + tl.repeatDelay(); But I think what Blake was saying is that it's not the timeline that has repeat: -1, it's one of the child animations, thus the timeline's duration() will be super long and the above formula won't work for that. So what you're basically asking (if I understand correctly) is "how can I calculate the duration of a timeline as if NONE of the children have any repeats?" Right? So yeah, that's much more tricky. I mean technically you could write a bunch of code to loop through all the children, alter the repeat() of each to be 0, and then check the timeline's duration() and then reset all the child repeats to what they were but that's a lot of effort. In my opinion, it'd be much cleaner to just use variables when you build out your animations such that you can easily calculate the iteration duration that you're after.
  3. Sure, you'd just need to set the start/end positions accordingly. And if you want it to rotate one way, then another (or whatever), you can just put those animations into a timeline, and the ScrollTrigger goes on that timeline and set scrub: true so that as you scroll, it simply scrubs through that timeline (when it's between the start/end scroll positions). My advice: set up your timeline by itself and get the square animating in the sequence you like (standalone). THEN hook it up to the scroll position using ScrollTrigger. If you get stuck, just post your minimal demo here and we'd be happy to answer any GSAP/ScrollTrigger-specific questions. Please read the forum guidelines, though - these forums aren't intended to be a place where you list your project requirements and then have us build it for you for free
  4. Good catch. I never really anticipated that someone would compound scrubbing like that where you've got a scrub on the containerAnimation AND on top of that another scrub on the ScrollTrigger that's watching that containerAnimation. Seems odd, but I guess it could make sense in some situations. It should be resolved in the next release which you can preview at https://assets.codepen.io/16327/ScrollTrigger.min.js But for now, I'd recommend scrubbing one or the other, not both
  5. Welcome to the forums, @pattyb! When a tween renders for the first time, it records the starting and ending values so that it can very quickly interpolate between them during the course of the animation. You are animating the "right" property, thus it records whatever it is initially (and that is based on the viewport width in your setup). When you kill() the ScrollTrigger, it reverts any associated animation to its starting values. So let's say in your case the viewport is a width that causes the right edge of your content to be 500px off the edge, thus right: 500px. That gets recorded as the start. Then when the user resizes, you're killing the ScrollTrigger which reverts to that 500px value (inline)...and therefore that serves as the start of the one you're re-creating too (I noticed your function gets called on every resize). See the issue? The solution is pretty simple once you understand what's happening - just wipe out the "right" value from your element BEFORE you create your new ScrollTrigger/animation: document.querySelector(".animatedCarousel").style.removeProperty("right"); this.animation = gsap.timeline({ scrollTrigger: { ... Does that clear things up?
  6. If Blake's suggestion doesn't deliver what you want, can you please provide a minimal demo that shows the negative behavior you described (you said the current demo works fine). That'd really help us craft a solution for your particular use case/context.
  7. Usually the only time I tap into that is if I need to account for potential "time leak", like if the playhead may have stopped at the start/end and time elapsed since then. For example, if I'm trying to do a seamless loop using an onComplete - let's say technically the animation was scheduled to stop at 1000ms and there's an update at 999ms and then the next update is at 1015ms so the onComplete fires but technically it was 15ms after it theoretically ended, I'd want to jump 15ms into the animation in the forward direction now instead of starting at 0. Make sense? It's exceedingly unlikely that anyone would notice that slight imprecision, but I obsess about things being accurate. Most other engines don't account for time drift like that which can add up over time and cause things to fall out of sync with other animations. Does that clear things up?
  8. Hi @yousoumar. It's super difficult to troubleshoot blind (without a minimal demo), but this sounds like something unrelated to GSAP/ScrollTrigger. Perhaps your video wasn't loaded or you encoded it without frequent enough keyframes to do smooth jumping to certain frames? Video is heavily dependent on the way you encode it and how the browser decodes. I'd also recommend checking to see if console.log(video.duration) returns what you expect when you plug it into the tween. If the metadata hasn't fully loaded, that won't accurately reflect things. If you still need help with something GSAP-specific, please provide a minimal demo, like in CodeSandbox.
  9. An animation's playhead isn't allowed to move beyond its start or end, of course. So for example, if your animation has a duration of 10, you'd never get a totalTime() of 11 because the playhead "stops" at the end. Think of rawTime() as the same thing except without those limitations, so it looks at wherever the playhead of the PARENT timeline is and figures out the corresponding time on the child even if it's beyond the start/end. So let's say you've got a 10-second animation that finishes and then 1 second later you check this: console.log(animation.totalTime()); // 10 console.log(animation.rawTime()); // 11 (that assumes that the parent playhead kept going, like it wasn't paused or reversed or whatever). Does that clear things up? It's not documented currently because I really wasn't sure it'd be useful to many people and I didn't want to clutter the API. If you all think it's worth officially documenting, I'm certainly open to that.
  10. Nah, not a "stupid" question at all. It wouldn't work because MotionPathHelper is supposed to let you add points, make them curvy, pull control points, etc. (total flexibility) which would all be impossible with a <polygon>. It's super easy to solve, though - just use MotionPathPlugin.convertToPath()! https://codepen.io/GreenSock/pen/RwLOOoe?editors=1010 Does that clear things up?
  11. Yep, that's because once: true will kill it as soon as you reach the end scroll position, and you've got a delayed scrub value which means the animation is likely in the process of being scrubbed at that point and is killed. I've added code to the next release to allow the scrub to finish in that case - you can see that in this fork: https://codepen.io/GreenSock/pen/GRMLYzW?editors=0010 But in the meantime, you can simply remove the once: true and do this instead: onLeave: self => self.getTween().eventCallback("onComplete", () => self.kill(false)), Better?
  12. Your demo has lazy: true instead of lazy: false Once I changed that, it seems to work great for me. Am I missing something? As for when the next version will be released, we don't have a specific date yet. It's likely in the next 4-6 weeks.
  13. Sure! How about this?: https://codepen.io/GreenSock/pen/vYeMzBr I added a roundDistance optional property to keep the rings synced up (the way your artwork is set up makes some of them in the same ring a bit further than others).
  14. I'm not really sure - maybe someone else will chime in but we really try to keep these forums focused on GSAP-specific questions.
  15. Sure, I'd probably create a timeline that animates each piece of text up (like a simulated scroll) and then hook that up to a ScrollTrigger that's got scrub: true and you can pin the section that it's in so the background stays put while the text appears to glide past, fade, or whatever (but that's just your GSAP animation doing that). Good luck! If you get stuck, feel free to post a minimal demo here with a GSAP-specific question.
×