GreenSock last won the day on May 4

GreenSock had the most liked content!

GreenSock

Administrators
  • Content count

    11,009
  • Joined

  • Last visited

  • Days Won

    303

GreenSock last won the day on May 4

GreenSock had the most liked content!

Community Reputation

4,188 Excellent

3 Followers

About GreenSock

  • Rank
    Administrator

Contact Methods

Profile Information

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

Recent Profile Visitors

42,072 profile views
  1. Yep, I just sent you a PM with the .swc. Please let me know if that works well for you.
  2. A catch-22 indeed, Blake. Yeah. The other tricky thing is that anytime we make something public (even "experimental"), we've gotta spend a fair amount of time documenting things, providing examples, etc., etc. And the API may evolve based on feedback, requiring more edits to docs. We're actually in the middle of rebuilding the tech that undergirds the docs (not the content of the docs - just all the plumbing for how they're built and displayed), so hopefully that'll make it a little less painful to do in the future. We've got a bunch of stuff we've been focused on, so it's tough to set those aside to push PathEditor out there (even in an experimental state), but I actually agree that it'd be cool to do at some point. We'll definitely keep it in mind.
  3. I was pretty excited about PathEditor when I created it, and thought it'd be cool to share but then I thought it could turn into a support nightmare due to the complexity and I'm not entirely sure it'd work perfectly on every touch device, etc. If enough people request it, we very well may release it (at least to club members) And yeah, Blake, I saw that Chrome extension and was equally frustrated with it.
  4. @duzhongkai I'm curious what made you ask about this. Were you just pulling apart the Ease Visualizer and got curious? Got a specific need for something?
  5. That's because you created conflicting/overlapping tweens of the same property of the same object. In other words, your first staggerTo() is moving xPercent to certain values, but then before those animations are done, you've got another staggerTo() that's trying to push xPercent to a completely different value, so the auto-overwriting feature kicks in and kills the first tween(s) when the second starts. That's expected behavior. I'd recommend against creating conflicting tweens. Or, you could set overwrite:false on the 2nd staggerTo() stuff, but that just tells GSAP to let the conflicts occur (two tweens fighting for control of the same properties). See what I mean?
  6. Thanks so much for the kind words, @manny2003! Happy tweening!
  7. Welcome to the forums & GSAP, @manny2003! I think you'll like it around here. By default, GSAP always applies transforms to the "transform" attribute of SVG elements because: That's what the SVG spec calls for They're more predictable and reliable across browsers. There are various quirks when transforms are applied via CSS styles in Safari, Chrome, Firefox, and Edge (different problems with each). We originally applied things to CSS by default and then later switched to the "transform" attribute in order to normalize behavior and conform with the spec. The main problem you're facing in that situation is that you end up with competing sources of truth. In other words, if the CSS has one value, and the transform attribute has a completely different value, which should the browser render? Some browsers prioritize CSS, while others prioritize the transform attribute. Yuck, I know. That's one of the reasons we always recommend setting values via GSAP whenever possible. Specifically: It works around browser bugs It allows GSAP to cache the values to improve speed It ensures rotational accuracy, especially beyond 360 degrees. GSAP can parse existing CSS that's applied to an element (it must do this to record starting values), but the browser always reports computed styles as matrix() or matrix3d() in which rotational values can get very muddy and it's actually impossible to decompose in a way that always discerns the original components. For example, rotations of 0, 360, and 720 would all result in the same matrix. When you mix in 3D stuff, it gets way more complex, like a rotationY of 180 would be the same as a scaleX of -1. In fact, there are infinite options and ways to decompose the values, and they often don't really match what went in originally. So when you set the via GSAP, they get locked in, cached, and always remembered so that it's perfectly accurate every time. No messing with decomposition, parsing a string of 16 values and trying to pull out the data, etc. Does that clarify things? Technically, in browsers that support it, you could set CSSPlugin.useSVGTransformAttr = false to tell GSAP to use CSS instead but it's not really something I'd generally recommend. We place a high priority on browser consistency and when it comes to SVG, CSS transforms aren't entirely reliable in my experience.
  8. Thanks for chiming in, Rodrigo. If I understood @UncommonDave correctly, he wasn't saying that the problem was the duration of the tweens. He's not waiting for things to finish normally - he's literally making all of their durations 0 (just for testing), but there's still a lot of processing time due to all of what GSAP must do (even with durations of 0) since there are so many tests that must be run. Is that correct, @UncommonDave?
  9. Understood, and I was totally kidding about the "just get a faster computer" thing. Tongue-in-cheek. Definitely keep us informed about your progress.
  10. Well, a set() is exactly the same as a to() with a zero duration, so that won't help much It might seem like it'd be simple to just immediately set the properties to their end values, but an animation engine is a very different beast than something like jQuery.css(). Keep in mind that: Even a zero-duration tween (set()) must record start/end values internally so that it can render at its starting state, ending state, or anywhere inbetween. Example: drop a set() onto a timeline and the playhead could be placed before, on, or after that spot and things must render properly. GSAP is highly optimized for runtime performance which can sometimes mean a bit of a tradeoff on the initialization code. Example: transforms are parsed and the components (x, y, scaleX, scaleY, rotation, skew, etc.) are separated out and stored independently in a cached mechanism which makes it very fast to work with on every tick. Overwriting is pretty critical in an animation engine, so GSAP must store some information about each tween and the properties it's controlling so that when another tween on that object starts, it can find that information EXTREMELY quickly and kill whatever aspects are necessary. Like if you're halfway through an "x" tween when another one gets fired off. There's a lot of optimized logic in place that, while it might look costly when you're only doing mocha tests with zero-duration tweens, actually make it possible for animations to run with butter smoothness at runtime. I wouldn't really recommend monkey-patching GSAP with mostly-empty functions like you're describing because it kinda defeats the purpose of the testing in some ways. In other words, you wouldn't actually be testing the real stuff - you'd be testing your hacked versions of the methods. See what I mean? I think it could get pretty messy too because you'd have to make a lot of very specific modifications to accommodate all the various values that plugins can handle. It's easy enough to just set "top" and "left" or "opacity" CSS properties in a monkey-patched set(), but how would you handle drawSVG, morphSVG, autoAlpha, svgOrigin, special transforms like x/y/rotation/scale, or the various browser inconsistencies that are handled automagically under the hood for transform-origin and a bunch of other stuff? I worry that you'd either miss stuff, or once you tackle it all perfectly, you'd end up with something that takes almost as long to process in your tests I wish I had an easier answer for you. Maybe just get a faster computer to make the tests run quicker
  11. Thanks for letting us know. Glad you got it resolved.
  12. I think I know what was going on, and I sent you a private message about it with an update to the plugin. Let us know if that works better for you. And thanks for creating the reduced test case. Very helpful.
  13. That means a lot coming from someone with 50 years of coding experience. Wow! Good luck with your project. Let us know if there are any other GSAP-related questions we can help with.
  14. I’m so sorry to hear about the disappointment. I just issued a full refund. Your satisfaction is guaranteed. We’re passionate about having happy customers around here and I’m really bummed to hear that you didn’t feel like the membership was worth the cost. And yes, if your goal was to have GSAP do all the physics logic in your game including collision detection and bouncing, etc., that’s not really what the animation engine was designed for. A physics engine is a totally different beast, and there are some significant down sides to physics engines that make it poorly suited for a tween-based system. Each has its pros and cons, of course. You could definitely use GSAP’s ticker to run whatever logic you want, but that doesn’t solve the problems you referenced regarding collision detection, bouncing, imposing boundaries, etc. I’m very sorry if we communicated things poorly on the site and gave you the wrong impression about what GSAP is for. To answer your question about the event callback, you could definitely do the collision detection in an onUpdate (or TweenLite.ticker.addEventListener()) and then just create a new tween at that point when you're changing direction. GSAP has auto-overwriting enabled by default so you don't even have to kill the old tween (though you could if you want). Happy tweening (or physics-engining)
  15. It looks like the TweenMax file isn't being loaded for some reason ("ERR_BLOCKED_BY_CLIENT" is what it says in the console). Not entirely sure why without seeing the client setup. Maybe an ad blocker extension or something? I don't recall ever hearing something like that before. But again, it doesn't appear to be a GSAP issue - it's a loading of the file issue.