Jump to content
GreenSock

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

GreenSock last won the day on July 24 2019

GreenSock had the most liked content!

GreenSock

Administrators
  • Posts

    13,198
  • Joined

  • Last visited

  • Days Won

    409

Posts posted by GreenSock

  1. Yeah, it looks like whoever made that plugin didn't account for multiple transform-related tweens (even if they're not overlapping). 

     

    If you need some consulting help building something (plugin), feel free to reach out to me privately and we can try to figure something out. 

  2. 13 hours ago, OSUblake said:

    My next guess for the issue would be that the .setNativeProps() calls are overwriting the style/transform objects. But that's just a guess. I've never used React Native.

     

    I think @OSUblake is right. Let's say your first tween is controlling translateX, but then you create another (overlapping one) for translateY. They're BOTH funneled through that 3rd-party "transform" plugin which only looks at the values passed into it. So while they're overlapping, the first tween will set the transform to the translateX value, and then right after that (on the same tick), the second tween will set the transform to translateY. So the translateX gets wiped out, replaced with just the translateY. 

     

    See the issue? 

     

    The plugin would need to take a more wholistic approach. In GSAP, we treat the _gsTransform object as a proxy of sorts, where each component (x, y, scaleX, scaleY, rotation, etc.) is stored/edited and then when a tween renders it pulls from that common object. I'd suggest that the 3rd party plugin could do something like that. 

  3. First of all, thanks for being an advocate for GreenSock at Zynga! ?

     

    And yes, I'm pretty sure that it's an overwrite issue. Try setting overwrite:false on your tween(s) or you could just set TweenLite.defaultOverwrite = false. 

     

    The plugin you're using doesn't look like it handles the overwrites properly. So every "transform" tween, when it renders for the first time, will kill any other "transform" tweens that are running at that time. See what I mean? 

  4. That's a pretty cool effect indeed. Definitely not a simple thing to explain how to do, sorry. I think it boils down to Cubic Bezier points that have some physics applied affecting their positions in relation to each other. I wish I had time to do a whole tutorial, but it's no simple task. 

    • Like 1
  5. 5 hours ago, OSUblake said:

    Maybe @GreenSock can quickly look at those plugins to see if anything stands out. 

     

    Yeah, I suspect it could be an overwrite thing or (more likely) mishandling of transforms. We had to do a bunch of work to ensure that all the transform components can be independently animated, plus a whole bunch of other transform-specific challenges. See https://greensock.com/transforms for details. I don't see them handling all that stuff in the "transform" plugin they created, but I'm not very familiar with exactly what they're doing, what constraints there are with native, etc. 

     

    I must admit it feels a little weird to be spending time troubleshooting a 3rd party plugin that's "borrowing" GSAP's API/code (ineffectively). ?

  6. Just so you know, you can use any of the bonus plugins on codepen for free. We created special trial versions which are all listed here: 

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

     

    I whipped together a helper function that'll simply invert an ease for you. Just feed in the ease and it'll spit back a new one that's inverted: 

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

     

    Here's the function:

    //feed in an ease and get back a new inverted version of it.
    function invertEase(ease) {
      if (typeof(ease) === "string") {
        ease = CustomEase.get(ease);
      }
      return function(p) {
        return 1 - ease.getRatio(1 - p);
      };
    }

     

    Does that help? 

    • Like 1
  7. Hi @Emilek1337. Welcome to the forums. 

     

    It sounds like you're talking about a simple yoyo. You can set repeat:1 and yoyo:true on a TweenMax or TimelineMax instance to get that effect. Or just reverse() the animation anytime. If you still need help, a codepen would be super helpful so we can just tweak things in your context. 

     

    Happy tweening!

  8. The jump is completely normal because of the way transforms work (totally unrelated to GSAP). If you scale something from its bottom left corner, it ends up at a completely different place than if you scale it from its upper right corner. 

     

    If you want to change it dynamically without the jump, you'd need to compensate its translation (x/y). Here's a fork of your codepen that uses a function I whipped together for that purpose: 

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

     

    The function is: 

    function smoothOriginChange(element, transformOrigin) {
      if (typeof(element) === "string") {
        element = document.querySelector(element);
      }
      var before = element.getBoundingClientRect();
      element.style.transformOrigin = transformOrigin;
      var after = element.getBoundingClientRect();
      TweenLite.set(element, {x:"+=" + (before.left - after.left), y:"+=" + (before.top - after.top)});
    }

     

    Does that help? 

    • Like 4
  9. Ah, if I understand your goal correctly, that's a perfect use case for advanced staggers and the "distributeByPosition()" helper function. 

     

    Here's a fork: 

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

     

    That helper function allows you to distribute the stagger based on the position of elements. Notice I set axis:"x" so that it only factors in the x-coordinate of the elements (by default it's both x and y coordinates). 

     

    Is that what you were looking for? 

     

    Here's more info on advanced staggers: 

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

    • Like 2
  10. There's internal logic to only use matrices in certain scenarios (mostly related to rotation). I'm pretty sure it's more performant to do it that way. If you're noticing a difference (negatively), can you please provide a reduced test case? I'd love to see it. I just doubt switching to matrix() would help at all when you don't have any rotation. 

  11. I'm not sure I understand the question - are you asking us to read through all the source code and show you how to rebuild it with GSAP? Or you just asking if it's possible? 

     

    As far as I know, GSAP can do everything anime.js can do plus a whole lot more (though I don't mean that as an insult to anime.js at all which I have lots of respect for). So yes, I'm sure it's entirely possible to do virtually any animation using GSAP. 

     

    Is there a particular GSAP-related question we can help with? I'd love to help, I'm just not totally sure what you're asking here. 

    • Like 1
  12. It is admittedly a gray area, yes, but as long as they're only using your tool to create these animations and they don't edit them apart from your tool, they wouldn't need to purchase their own license unless they're charging multiple customers too. In other words, the standard "no charge" license would apply to them (and we'd appreciate it if you made that clear in your licensing doc to your users). Otherwise it would obviously create an easy way to circumvent the GreenSock license. But my guess is that most of your customers will NOT be using these animations in a commercial context like that and they won't be editing things apart from your tool (and I also assume your tool wouldn't be directly competing with GreenSock), so their usage would be covered by your "Business Green" license. See what I mean? 

     

    The posture we take with licensing in general is to work hard to keep it from being an impediment while at the same time being responsible about creating a funding mechanism that'll ensure ongoing development and support. Sometimes it's a fine line. Are there some situations where we risk being taken advantage of? Sure. But we firmly believe that most users want to do the right thing and they'll eventually support our efforts because ultimately it benefits them too (especially the ongoing support). We trust that if we just keep putting value into the marketplace, it'll respond and we'll be just fine. That gives us confidence in cases like this to air on the side of generosity and leniency. We hope that'll also translate into happy customers who are very loyal and spread the word about GreenSock. ?

     

    Thanks again for caring enough to understand and honor the licensing terms. We love serving users like you. 

    • Like 1
  13. Oh, we'd be happy to answer any questions about ScrollToPlugin or GSAP or anything like that. But from what I can tell, this has nothing to do with any of that. 

     

    I did notice that you've got your click event handler using this selector: ".smothscrollclass a[href^='#']" but your "about" link does NOT start with "#", thus it never triggers that event handler. It just treats it like a normal link. I didn't see any dynamically-loaded things, so maybe your codepen isn't representative of the real context, but maybe you just need to fix your selector text for your click handler. Or maybe I'm misunderstanding your goal/question. 

     

    Was there something about GSAP that we could help with? 

    • Like 1
  14. Welcome to the forums, @hybreeder. This sounds like more of a ScrollMagic or general question rather than a GSAP-specific one. You might want to ask the author of ScrollMagic (it is NOT a GreenSock product) if you're having issues related to that. I'm not very familiar with it. I wish we had the resources to answer everyone's general questions or questions about 3rd party products, but definitely let us know if there are any GSAP-specific things we can help with. 

  15. It looks like you forgot to import ScrollToPlugin. And you might want to reference it directly in your code somewhere just so your bundler doesn't dump it with tree shaking. 

     

    As for the rest of your question, it sounds like maybe it's more Vue-specific but correct me if I'm wrong. We're happy to answer any GSAP-specific questions. I'm personally not familiar with Vue. 

    • Like 1
  16. There were several problems. First, you were using document.getElementsByClassName(".st1") which returns a NodeList (like an Array), but you were treating it like it'd return a single element (by appending .addEventListener(....)). You can't addEventListener() to a NodeList/Array. 

     

    Also, you used the wrong selector text. It should simply be "st1", not ".st1" because you're using getElementsByClassName(). I'd recommend switching to document.querySelectorAll() which is more flexible and you can use that selector text (".st1"). 

     

    You had logic that'd cause things to grow when the mouse LEAVES them (instead of when it rolls over them). I assume that behavior was inverted, based on what you said in your question. 

     

    I wasn't sure if you wanted each piece to animate independently, but here's a fork:

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

     

    Does that help? 

    • Like 3
  17. I noticed several problems:

    1. You still appear to be loading external SVG assets. The browser will not allow you to access the contents of those, so you can't morph them because it'd require JavaScript reaching in and altering them (a security violation). You must inject the SVG inline. Like...literally, the SVG code itself must be in the DOM (not an <object> or <img> tag)
    2. Your codepen has <html>, <head> and <body> tags, as well as <script> tags pointed at invalid addresses. None of those should be there (codepen puts the html/head/body tags in place automatically). 
    • Like 2
  18. Yep, @mikel and @Jonathan are exactly right. Also, I'd strongly recommend using yPercent:200 instead of y:"200%" so that you're very explicit about the effect you want. Technically what you have will work in this case because internally GSAP noticed the % and converts it internally to be yPercent for you, but keep in mind that you can combine "y" and "yPercent", so if you tried doing another tween later to something like y:100, you'd end up with BOTH y:100 AND yPercent:200. It's just safer to be explicit and use the built-in yPercent or xPercent whenever you do percentage-based transforms.

     

    Another minor note: your SVG is using a crazy-high amount of precision in the numbers which makes the strings VERY long. If you clean that up so that it uses only one or two decimal places, you'd probably cut the size of your SVG string in less than half kb-wise. Faster loading, and I doubt anyone would ever notice a difference in the visual fidelity. Just a suggestion. 

     

    Happy tweening!

    • Like 2
×