Jump to content

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

GreenSock last won the day on April 8

GreenSock had the most liked content!


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by GreenSock

  1. Very nice work, @PointC! 🙌 And @OSUblake also gets bonus points for making use of another GreenSock tool Happy tweening @nikolev!
  2. Yeah, your shape does NOT have the extra points at the bottom. I just updated the codepen-only MotionPathHelper file to add an editPath() method so that you can see what I mean: https://codepen.io/GreenSock/pen/8fcb337385d0f1e401a66f260cf73e76?editors=0010 Look at the anchors. No extra points along the bottom. Maybe your software is stripping them out when you save?
  3. Nah, sorry about that - I'll just have the plugin ignore that property as a "real" one (it's only for when you're doing a filter-related animation). As you discovered, it doesn't actually cause any problems. You can safely ignore that warning in the console. You can preview the upcoming release with that fix at https://s3-us-west-2.amazonaws.com/s.cdpn.io/16327/PixiPlugin3.min.js
  4. Do you mean a "section" that you scroll to? You want to pause the animation until the user gets there? That's what our new tool will handle. For now, you could certainly accomplish that with something like IntersectionObserver or manually watch the scroll position. I don't have a pre-baked solution for you right now, sorry. There are plenty of threads in the forums that discuss IntersectionObserver. Happy tweening!
  5. Welcome to the forums, @Christos Tsangaris! Unfortunately ScrollMagic isn't a GreenSock product and we don't really recommend using it. You could try contacting the author with your questions, but I don't think he's been very active for a while. The good news: we're working on a GreenSock tool that can do very similar things to ScrollMagic. I think you're gonna love it. But it may not be available for another 3-6 weeks (no promises...we're in the early stages right now). Good luck with your project! Let us know if you have any GSAP-specific questions. We'd love to help with those.
  6. Hm, I don't think your SVG has the edited points from your screenshot. I'm still seeing this: https://greensock.d.pr/gCY0WP Didn't you say you added a bunch of points to the bottom? I'm also curious - what program are you using? Do you have an EPS/PDF/AI file? I'm just curious. Illustrator wouldn't open the SVG; it's like there's something malformed in the paths. And there are some very large transforms applied needlessly.
  7. Hm, can you provide a codepen? I wonder if maybe you left the shapeIndex: 20 that you had in there. That'd certainly explain things looking strange.
  8. Yeah, since you've got a very different number of points in the end shape, MorphSVGPlugin has to add them in artificially and you've got a disproportionate amount clustered at the bottom. In cases like these, asset prep is key. So I'd suggest adding a similar number of points to the bottom of the STARTING shape so that when it morphs, it more naturally finds ones at the bottom to map to. I very quickly added some to the bottom here and you can see that it improves things (but I'm sure you could get it better): https://codepen.io/GreenSock/pen/193d53a53f3896608254829409700973?editors=0010 Here's a screen shot of where the points/anchors are on each shape: https://greensock.d.pr/oT3ksO If you want it to be REALLY good, you could start with the un-melted shape, add a bunch of smooth points to the bottom of it (but DON'T actually drag them down to make it look melted yet - just add the points first so the shape looks completely unmelted). Then copy that shape and pull the points down and position them to make it look melted. Then morph between those shapes. It'll map the points perfectly. Does that help? And welcome to the club! Thanks for joining. 🙌
  9. Sure, that's possible. The problem is that you're converting to the wrong coordinate space - if you want to apply transforms to the blue-box, those coordinates would actually be in the parent element's space. In other words, you were converting things into the blue-box's coordinate space (like...inside of it), thus if you move -100px for example, it'd actually look like it's moving a lot less because the blue-box is already scaled down. I put together a function for you that'd do the conversion: https://codepen.io/GreenSock/pen/8871a41b7d65dd82c153d693c8f2141e?editors=0010 Technically you should be able to use the getRelativePosition() method for that but it's very late and my brain is foggy right now so I'm not sure why that's not working. I'll have to look into that a different time, but the helper function in the codepen above seems to do the trick just fine. Happy tweening!
  10. Are you 100% positive? And was that GSAP file loaded BEFORE the code that references TimelineMax? Did you check the source of the page that's displaying that error (I mean in the browser, right click, view source)? If you are indeed loading that on a page then TimelineMax will be defined (after it's loaded of course). So it's either an order issue (you're referencing TimelineMax before the file loads) or you're not loading GSAP or maybe the code that's looking for TimelineMax is in a different iframe or something, thus it doesn't have access to GSAP from that page. Very difficult to troubleshoot blind.
  11. Interesting - it looks like PixiJS is now returning a string for the property, but in a hexidecimal kinda way like "0xFF54CC" instead of "#FF54CC" or a regular number, 0xFF54CC. I'll update the plugin accordingly in the next release. You can preview it here: https://s3-us-west-2.amazonaws.com/s.cdpn.io/16327/PixiPlugin3.min.js
  12. Sorry about that! I mistyped - it should be gsap.config(), not gsap.defaults().
  13. In GSAP 3, you can do it like this AFTER you registered the plugin: gsap.config({autoKillThreshold: 1}); 👍
  14. That sounds like an issue in your bundler related to tree shaking. You are importing gsap on that page where you're referencing it, right? It's tough to diagnose blind, buy here are a few guesses: Try doing import { gsap } from "gsap"; instead of import gsap from "gsap"; Make sure you're actually importing GSAP on the page/module where your code is that references "gsap". The error sounds like maybe you've got some code that references "gsap" somewhere that's OUTSIDE of wherever you're doing your import(s). Remember, when you import GSAP as a module, it does NOT add itself to the global scope. That's a GOOD thing (it helps keep things encapsulated). You can add all the GSAP globals to any object (including the window, as in this example) like: gsap.install(window) I noticed you have a dependency of "@types/gsap": "^1.20.2" but that's a 3rd party thing that was developed for the OLD v2 and earlier of GSAP. Delete that. Typescript stuff is now included with the official GreenSock files. I'm not sure what else to suggest. Maybe someone else will chime in with an idea. But you definitely should NOT need to set window.gsap = gsap. It sure sounds like you must have code somewhere outside where you're doing your import and that's causing the problem. Happy tweening!
  15. We really pride ourselves around here on maintaining a friendly, positive, non-snarky tone (unlike many other forums). Very sorry to hear that Blake's response came across as dismissive - I totally didn't see it that way. He's a legend around here and he even provided some demos that I thought could be very useful for your scenario but maybe I misunderstood what you were after. I see your point about modifiers potentially causing 4 redraws for each tick on each line. If I were in your shoes, I'd totally do what Blake was suggesting and use generic points almost like proxies - animate only those values (coordinates) and then in a single onUpdate (or tick listener) do all your redrawing in one fell swoop for all lines/shapes. I'm pretty confident that'd perform the best. As others have said, if you really want top-notch performance my guess is that the SVG rendering lay is BY FAR the biggest bottleneck, so perhaps consider using something like PixiJS or raw canvas or something like that. In almost every case I've seen, GSAP code is only a tiny fraction of the overall load on the device. When things get jittery, it's typically like 98%+ graphics rendering and only 0.1-2% animation code execution (CPU load). Thanks for being a Shockingly Green member, @pragdave. Is there anything else we can do to help?
  16. Here's one other way to approach the flipping of the car: https://codepen.io/GreenSock/pen/ExjJOWp?editors=0010 We apply autoRotate: true and then in an onUpdate, we get the current rotation and if it's within a certain threshold, we invert the scaleY. I even snuck in some helpful utility functions in there Happy tweening!
  17. Actually, it's fine to set a z value in transformOrigin - GSAP simply handles that all internally and bakes it into the transform value in order to work around some browser bugs. Like in Safari, if you use a 3D transformOrigin, it breaks things in several ways. Here's a demo comparing GSAP and anime.js (look at it in Safari): https://codepen.io/GreenSock/pen/8c1acc1074fa8c9e705d7cd66ff625f4 It's not that it's a bug in anime.js - it's a browser bug that anime.js doesn't work around, that's all. GSAP does the extra work to ensure your animations "just work" - that involves removing the z component from transformOrigin and adjusting the translation values accordingly. As for scaleZ, frankly I've never seen any use for it whatsoever. It isn't something GSAP supports (didn't want to waste the kb or CPU resources on something that's pretty much useless in the real world...at least from what I can tell). Can you provide a practical use case for it?
  18. Hey @ClareBee! Welcome to the forums. Are you using the latest version of Draggable? 3.2.6? And yeah, it'd be helpful to see the problem in context but it's really tough if you just send your entire project. It's always best to create a reduced test case with only the absolutely essential code to reproduce the problem. I'm not just recommending that for our benefit - it's just a good habit on your end too because that practice might expose the issue before you even need to ask us about it. I'm not sure we can support your "old janky Motorola" to be honest. You may need to hunt for a way to disable the context menu for your particular browser. I wonder if it's just so old that it can't be worked around because the browser is so ancient (?)
  19. Good catch! This is quite the edge case that'd only affect the "display" property that's animated with the sine ease. The reason is that Math.cos() of half Math.PI ends up being a super tiny number instead of 0, thus when the progress of the tween is 1 and that's fed into the sine ease it comes back as 0.9999999999999 instead of 1, thus the condition isn't met that's necessary to toggle that property. It should be fixed in the upcoming release which you can preview at https://s3-us-west-2.amazonaws.com/s.cdpn.io/16327/gsap-latest-beta.min.js In the mean time, you could simply use a set() to toggle that value (it's not tweenable anyway - we just have it as a convenience).