Acccent

Hey SoL2Squiz, In addition to what @PointC descrbed, you can use .fromTo: TweenMax.fromTo(".logo", 3, {autoAlpha:0}, {autoAlpha:1}); What it does is let you specify the starting values for an animation (in this example, autoAlpha:0) as well as the end result (autoAlpha:1 here).

Well, one simple solution is to call the randomstars function when tlStars is complete, instead of having the animation loop forever. That way it creates a new animation with new values. You can see it here: http://codepen.io/Acccent/pen/RrYEaL?editors=0010

@Carl, I do feel welcome here and like to come by once in a while to see if I can help with anything – but usually, folks like @PointC and @Jonathan are already providing invaluable help. Which is why I never doubted that they had nothing but the best intentions! However, since new threads on here are often about users needing help with very specific issues with regards to how GreenSock works, concrete scenarios, I assume that my more 'general' question was kinda unexpected, haha. Of course, I'm the one to blame if I didn't manage to put my point across clearly enough For my part, there is not an ounce of ill will, nor do I hold the shadow of a grudge against anyone haha. I am always impressed by how civil these forums are. You have my apologies if I disturbed the peace @ @PointC: I do understand that you can group a single element to achieve the kind of manipulation shown in the article, however it's not obvious at first glance that it would be needed to create such a group. I made (yet another ) codepen to show that the exact same transform yields different results with CSS and GSAP: http://codepen.io/Acccent/pen/MKqxqZ . The reason for the difference is because, with CSS, the element's coordinate system is transformed along with the element itself, while it isn't with GSAP. This isn't a case of 'what's worse or better', it's just something that new users should be aware of, so it's probably worth mentioning in the new thread that Carl will create

Yes, at least this very thread will hopefully show future users how to avoid the things that I might have had a hard time with in the past! Regarding Sara Soueidan's article, I actually believe that she isn't transforming a group at all. (Well, she is transforming the 'parrot' group, but for the purposes of this discussion it can be considered a single element.) She mentions the following: So, to take your pen as an example, here's a fork that more closely illustrates the difference with the article: http://codepen.io/Acccent/pen/bExzdb In it, if it behaved like in the article, the square on the left would move diagonally. (However, like I said, I also think it's a good thing that GreenSock behaves the way it does.) Thank you for your patient and cordial replies

Hi @dghez, I believe I solved the issue... I was just cleaning up the code to understand it and fixed it without realising. http://codepen.io/Acccent/pen/RrYEaL?editors=0010 I think the issue lied within your randomstars function. I changed the TweenMax that were inside with a TimelineMax, that is paused when you click on Let's Start (before tlLeaving starts). tlLeaving is also invalidated before starting so that it acknowledges the current positions of the stars and ovals. Be aware that I also removed the 'leaving' variable which I think wasn't very useful, and tlFunny which was unrelated to the problem. Let me know if this helps

I do not understand why the replies are so defensive of GreenSock. I am not criticising the platform! I'm very happy with it! @Jonathan, you can't really expect someone to read the entire SVG spec to understand how to use GSAP... It's incredibly tedious to go through. You don't need to read the spec to understand how to use basic CSS transforms such as translations or rotations. I agree that if a user tries to apply a 3D rotation to an SVG, that's not a fault with GreenSock... But that's really not what we're talking about here. And it is kinda illogical, in my opinion, to claim that just because GreenSock is a tool, there is no difference between it and Illustrator. Illustrator is a tool as well... and they treat some information differently... so how is that not a difference? The article you linked is very interesting, but it actually confirms some of what I'm trying to point out... for instance, have a look at this extract, from part 2: and the accompanying image: Now check the codepen I made earlier ( http://codepen.io/Acccent/pen/eJLWyy?editors=1010 ). As you can see, even though I'm chaining transforms, the translation is done parallel to the initial coordinate system, not the one that results from the rotation. Maybe I am missing something here. I'm not even complaining about this behaviour: I find it easier to understand and more predictable. I just thought it would be useful to have some kind of resource that mentions this. I agree that it's not on GreenSock to provide the kind of document/article that I was asking about. I was simply wondering if someone who extensively knows and uses GSAP might have written that kind of information somewhere. I'm certainly not knowledgeable enough to do so, but maybe a professional web designer or graphic designer or UX designer somewhere had done it already.

Well – I'm sorry if I wasn't clear enough, and I really appreciate the post, but as I showed on the codepen I knew all of that already. I'm just saying: precisely! You need to know this! And it's not documented anywhere on official GreenSock pages, as far as I know, so you kinda need to either guess or just stumble into it once or twice to figure it out. And it can be a pain to understand what's going on if you don't know beforehand. It's not really an issue of GreenSock 'allowing' scalable transforms, it's just a specifity. That's what I meant by 'quirk', and I hope the word didn't imply any negativity because that was not my intent: again, I don't think it's a problem with either GreenSock or Illustrator, it's just that they work in slightly different ways, both equally valid. I would probably say the same thing about InkScape or other vector software, but I happen to mostly use Illustrator. To take your example, what I'm saying is if you applied Illustrator reasoning to GreenSock, and wanted to move the rectangle to the right side, you would use x: "900" regardless of its initial position. (ie. use values relative to the whole SVG document rather than the individual element.) You would also use this value even after scaling the parent element, since the 900 value is relative to the SVG canvas which is also scaled, if that makes sense. So really, it's not an issue of one approach allowing more things than the other, they're just slightly different. And, anyway, that specific example is just that: an example! I was wondering if there was either a compiled list of these 'things to be aware of' somewhere, or a documented workflow, or procedure, or method... that avoids the pitfalls, or at least takes steps to correct the resulting problems and mistakes. If there isn't, that's no big deal, I'll just continue learning through practise rather than theory

That video is super interesting and exactly the kind of thing I'm looking for! One of the things he mentions which I think is important to know if you want to start animating SVGs using GreenSock, is that when applying an x transformation to an element it's always calculated relative to its position, not the whole document's. So, you were wondering about what kind of specific situation I'm trying to avoid in the future, and I guess I can elaborate on that and the thing I alluded to in my first post... Say you want to recreate something as simple as the cover of Jamie XX's Far Nearer. Obviously the first thing you want to do is simply draw a rectangle in Illustrator, then rotate it by 45°. But when you do that, and have a look at the generate SVG code, you get a transform matrix, which admittedly you could give to GreenSock but then it's not very legible at all and pretty much removes your ability to tweak it out of Illustrator. But even without rotating it, if for any reason you want that rectangle to move around... You – at least, I – create the SVG in Illustrator that corresponds to the starting state, then note that down into the html, then go back to Illustrator to move the rectangle to where I want it to go, and look at the new SVG code to use it with Greensock... except that doesn't work, because the values that Illustrator shows aren't usable by GreenSock. Have a look at this codepen: http://codepen.io/Acccent/pen/eJLWyy?editors=1010 In it you see that the rectangle has a starting position of x="20" y="20". Let's say I move it just a bit down in Illustrator so that its end coordinates are x="60" y="100", and then look at the SVG code: I get <rect id="movingrectangle" fill="#22FF99" x="30" y="90" width="60" height="20"/>. Now as you can see in the codepen, if I give those new values to GreenSock, it really doesn't move the rectangle 'just a bit down'. I couldn't find a way to go just where I wanted it to, except by using relative values. edit: by the way: Chris Gannon says in the video that the relative positioning quirk only applies to paths and not other SVG elements, but it does happen with a rect as evidenced in the codepen. I'm not saying Illustrator or GreenSock is at fault here, just that it would be useful to know a general method to move from one platform to another without this kind of issues cropping up!

Hey there I was simply wondering if there existed, somewhere, a practical workflow that one could follow when working with SVG – the aim being to streamline the process of creating SVG in Inkscape or Illustrator, then translating it into markup that GSAP understands. I am not facing any particular issues at the moment, but I just finished working on an animation and it did cause some head-scratching. For instance, if you save an Illustrator project as an SVG file and then look at the code, and paste some of the information on there in your JS files to feed them to GreenSock, the result often differs. The reason for that is that, when you apply some transforms to your shapes in Illustrator, the software interprets some of it as actual transforms (which go into a transform matrix) and some of it as simply changing the shape's x and y coordinates. Then, when you enter the same info into your code, I think GreenSock just converts it all to a transform matrix, leading to varying (and sometimes wildly unexpected) results. Add to that traps like unaccounted-for changes in transform origins... and it can get pretty messy. I'm not looking for a solution to the situation I described above, nor for explanations as to why it happened the way it did... like I said, I don't actually face any problem at the moment I'd just like to know if there are best-practices and methods that are compiled somewhere that I could learn, to save some time for a future project. There's http://greensock.com/svg-tips, but that only provides examples of how GreenSock achieves various effects, not how to integrate all of those together and within a larger workflow. As an example, I know that it's usually more efficient to use relative values in your GSAP code instead of relative ones (like x:"+=10"). I'm not sure I would be able to explain why, but I found that it led to less errors – not on GSAP's side, mind you, but on the translation from vector-editing software to JS code. The issue's on the human side more than anything Cheers!

Hi ice-frog, You could try using Greensock's native syntax: http://codepen.io/Acccent/pen/bVLEQE In your carousel pen, try using something like: var tl = new TimelineMax(); tl.set('.card',{ width:110, height:149, backgroundImage:'url(http://www.zhuzhouzhixin.com/H5/demo/bt01.png)', backgroundSize:'100% auto', backgroundRepeat:'none-repeat', position:'absolute' }) .staggerTo('.card', 0, { cycle:{ rotationY:function(i){ return 30*i; } }, transformOrigin: "50% 50% -300px" }, 0); (This doesn't exactly work like you intend it to, but it should help you I think.) Someone else will probably be able to better explain the difference between using transformOrigin and a z transform by itself... Good luck

Thanks a lot! After changing the TweenMax.min.js version, and Math.Pi to Math.PI (sigh), I got it to work http://codepen.io/Acccent/pen/yYPJOL var eyeL = $("#eyeL"), eLx = 1*eyeL.attr("cx"), eLy = 1*eyeL.attr("cy"), tl = new TimelineMax({paused:true, repeat:-1}); tl.to(eyeL, 1, { ease: Linear.easeNone, onUpdate: rotatesvg, onUpdateParams:[eyeL] }); function rotatesvg(el){ var a = eLx + Math.sin(tl.progress() * 2 * Math.PI) * 20, b = eLy + Math.cos(tl.progress() * 2 * Math.PI) * -20; TweenMax.to(el, 0, {attr:{cx:a, cy:b}}); } This makes the left eye in the codepen rotate in Chrome and IE (can't test with FF at the moment). There's a caveat: on each update of tl, the rotatesvg function is called, which instantly moves the circle to the next point. There's no smoothing, and you can indeed see a slight difference between the two eyes in Chrome. If you could pass to the onUpdate function the delay between each step of tl, then you could specify a duration for the TweenMax in rotatesvg(), and it would be smoother. This could probably be implemented in GSAP? It could be used when you use rotate: inside attr:{}, since it provides a cross-browser solution for svg rotation, which the CSSPlugin doesn't have.

Hi If you've read this thread you know I've been trying to animate SVG masks. From what I gather, this is only possible by manipulating the SVG attributes directly, not with CSS transforms – which makes it easy for things like a circle's radius, but less so for rotation. Here's how I've attempted to do it (you can check the linked codepen): tl.staggerTo(el, 1, { cycle:{attr:function(){ var a = {cx:0, cy: 0}; a.cx = Math.cos((tl.progress() - 0.5) * 2 * Math.Pi) * 20; a.cy = Math.sin((tl.progress() - 0.5) * 2 * Math.Pi) * 20; return a; }}, ease: Linear.easeNone }) The goal is to change the cx and cy attributes over time so that the SVG element moves along a circle. There are two problems: using cycle and attr in conjunction doesn't seem to work? The function returns an object that should look like {cx:..., cy:...} but it's not interpreted correctly. I suspect I'm doing something really wrong here that has to do with not knowing javascript enough... here I'm trying to use tl.progress() to calculate cx and cy depending on the animation's progress, but this approach doesn't work; the progress is always 0 when accessed within the timeline itself I think, since the calculations are made prior to it running. How could I make it update properly? Using an onUpdate function, maybe? Cheers

I've changed the stars layers to use transparent pngs, though the version that's currently online isn't very pretty. We'll see how that affects performance. As for the konami code, you'll see the effect on the side panels, it takes a little while to activate

Alright I think I fixed the staggering somewhat. I previously had: slide .addLabel("left", 0) .from($leftsec, 1.2, { xPercent: 100, x: 0 }, 0) .from([$scenes, $rightsec], 1.2, { xPercent: 55, x: 0 }, 0) .from([$scenes, $leftsec, $rightsec], 0.6, { rotation: 0, z: 0 }, 0) .from([$scenes, $leftsec, $rightsec], 0.6, { rotation: 0.01, z: 0.01 }, 0.6) .from($deployarrows, 1.2, { rotation: -60 }, 0) .addLabel("center", 1.2) .to($rightsec, 1.2, { xPercent: -100, x: 0 }, 1.2) .to([$scenes, $leftsec], 1.2, { xPercent: -55, x: 0 }, 1.2) .to([$scenes, $leftsec, $rightsec], 0.6, { rotation: 0.01, z: 0.01 }, 1.2) .to([$scenes, $leftsec, $rightsec], 0.6, { rotation: 0, z: 0 }, 1.8) .to($deployarrows, 1.2, { rotation: 60 }, 1.2) .addLabel("right", 2.4); and to animate it I used one of the following lines, depending on the situation: slide.tweenTo("left", { ease: Power1.easeOut }); // OR slide.tweenTo("center", { ease: Power1.easeOut }); // OR slide.tweenTo("right", { ease: Power1.easeOut }); I changed all of that to this: slide .addLabel("left", 0) .from($leftsec, 0.8, { xPercent: 100, x: 0, ease: Power1.easeInOut }, 0) .from([$scenes, $rightsec], 0.8, { xPercent: 55, x: 0, ease: Power1.easeInOut }, 0) .from([$scenes, $leftsec, $rightsec], 0.4, { rotation: 0, z: 0, ease: Power1.easeInOut }, 0) .from([$scenes, $leftsec, $rightsec], 0.4, { rotation: 0.01, z: 0.01, ease: Power1.easeInOut }, 0.4) .from($deployarrows, 0.8, { rotation: -60, ease: Power1.easeInOut }, 0) .addLabel("center", 0.8) .addPause("center") .to($rightsec, 0.8, { xPercent: -100, x: 0, ease: Power1.easeInOut }, 0.8) .to([$scenes, $leftsec], 0.8, { xPercent: -55, x: 0, ease: Power1.easeInOut }, 0.8) .to([$scenes, $leftsec, $rightsec], 0.4, { rotation: 0.01, z: 0.01, ease: Power1.easeInOut }, 0.4) .to([$scenes, $leftsec, $rightsec], 0.4, { rotation: 0, z: 0, ease: Power1.easeInOut }, 1.2) .to($deployarrows, 0.8, { rotation: 60, ease: Power1.easeInOut }, 0.8) .addLabel("right", 1.6); (basically adding a pause in the middle, the easings, and adjusting the durations) then used this to actually trigger the animation: slide.reverse("center"); // OR slide.play("center"); //OR if(slide.reversed()){ slide.play(); } else { slide.reverse(); } It seems to have smoothed out the sliding animation, and made it more consistent. There still is some staggering/stuttering, but maybe that's because of how heavy the page is to re-render. If you want to have a look at the 'normal' code, it's here: http://robin-v.net/wp/wp-content/themes/paral/js/js-code.js And for the 'non-GSAP-version' (for the sliding), which is used on http://robin-v.net/testing, here you go: http://robin-v.net/wp/wp-content/themes/paral/js/js-code.dev.js The relevant parts are in the variable declarations at the top (the TimelineMax named slide) and under the 'Deploy sections' header. I don't think anything else matters in this case, but feel free to have a look Thanks again for taking the time to comment on this... I probably won't be very available in the coming week to help with debugging/testing, but I'll try to check this thread to answer to questions if you have some. If I can contribute to making Greensock more powerful, I'd love to. (Of course, if you don't want to spend more time on this, I absolutely understand, I already am super grateful for the help!) edit: I also disabled the slide-triggering buttons until their initial fade-in was over, so that probably helped too I think. No risk of positions being registered at the wrong moment etc.

Thanks for the great answer, Jonathan! I knew about <defs> and <use> but I'll have a closer look at the spec to see what's possible. Maybe I can achieve the same effect by animating a filter. I'll let you know. Thanks again The Greensock community has been super helpful and welcoming!

Oh, no, I'm not suggesting it's GSAP's fault at all, sorry if that's how I came off. Like I've said elsewhere, I know it's a very powerful platform and I trust it to do everything it does as well as it can. But I was just wondering if someone might know of an different way to achieve a similar result... Would clip-paths work, for instance? edit: in any case, it might be a good idea to mention this sort of caveat in articles like this one, to prevent people like me from finding out about them too late

Hi everyone If you've been following my threads: this is the last bit of animation that I need to do, the thing that I picked GSAP for... animating SVGs. Up until earlier today I was having trouble implementing this, but... it was totally my fault, some sort of typo among the variable declarations messed it all up. Whoops... Anyway, I fixed that and got the animation to work in Chrome just like it did before I moved to GSAP! So I switched over to FF where it was having issues, and... well the same issues are still here? It seems you can't change the transform-origin of masks in Firefox (or IE, for that matter)? Check out the (fun) pen I made to illustrate the issue. It works perfectly in Chrome, and when you open it in FF you see that the transformOrigin var isn't working. Ideas on how to fix this...?

Thanks for having a look Jonathan and thanks for the compliment! The long CSS string is for all the moving stars on the homepage. The alternative is to have small transparent PNGs, I don't know if that would be more cost-effective? I'll try out your suggestions of adding a small rotation and z translate edit: I've added a small secret code to disable the parallax effect – type '!!!' anywhere and it should stop (on both the normal and 'testing' pages). There's a console output to confirm that your input worked, too. edit again: the GSAP version that's currently live has the small rotation and z transforms. I don't see any notable improvement... (I think GSAP was already using translade3D anyway).

Hi Alright, I set something up. On http://robin-v.net you'll see the GSAP'd version, and on http://robin-v.net/testing the sliding transitions are only handled with CSS (on top of that, I don't load jquery.gsap.js – I thought that might slow down the parallax plugin I'm using. I don't know if it helped or not, I'm only mentioning it just in case.) Note that I put together the CSS version quickly, so some things might not be 100% identical. The CSS version works more reliably and consistently, based on my testing... sometimes in the GSAP version after sliding towards one side you end up stuck there, the 'Back' button doesn't work. Sometimes the buttons on the side don't slide into view on page load. Sometimes there's quite a lot of staggering going on (especially on FF), and/or the animation speed is variable, whereas the CSS transitions pretty much always behave the same way. I don't know if that will help; unfortunately I am 100% out of time and won't be able to debug that or provide a simplified codepen. Migrating to GSAP took around a week when I expected it to require two days at most, and to make things worse the reason why I did in the first place – to animate an SVG consistently across browsers – I haven't managed to do (yet). (Maybe you can't animate svg masks with GSAP?) So, yeah, I'm sure the platform is very powerful, and I really don't mean to come across as just wanting to complain or bash Greensock... but to be honest, I had to learn its somewhat dense syntax (that's to be expected when you have this many features, but still), in the end my code ended up way more complicated (maybe that's specific to my case), I don't see any performance boosts anywhere and I see some degradation in some places, and the thing I wanted to do I still couldn't see how.

Quick update: you can see all of the things I've posted about in action on my website, http://robin-v.net/ However I'd like to point out that the sliding animation that this thread was about was faster and smoother with CSS transitions, so I'm a bit disappointed. It took a lot of time and effort to make all the necessary changes and I end up with something worse Anyway, thanks again for the help, everyone.

It's all detailed on the home page

Okay I fixed it! I just had to move tl.seek() in Diaco's pen before the TweenLite that updates the panel's position: http://codepen.io/Accent/pen/WQZYaQ Now it all works, although to be honest I still think it's a tad complicated, but it'll do!

Well, now it's incorrect in the very first position the blue box is out of the 'window' there.

I'm afraid this doesn't work either (click slide, then resize, then slide again – it doesn't go back all the way) but I'll try to work something out from it and let you know if I manage to get something. (Feel free to post other suggestions in any case! Thanks a lot for your help )

Diaco, I had checked invalidate() (it was in the pen) and the two examples you posted (my pen was a fork from one of these). I changed it so that it uses xPercent and the initial transform is set with a TweenMax. It does work better, but as you can see the x value in the transform is still always the same; how do I make it change depending on the window size? If I do something like clear() the Timeline and add a new tween to it with the correct value on window.resize, then the Timeline's current state will be lost I believe, and the next time the user slides the panel it won't work properly... edit: link for convenience http://codepen.io/Accent/pen/BowwZx edit again: In case what I'm trying to do isn't clear or seems very complicated, here's a CSS-only version: http://codepen.io/Accent/pen/dYVQPZ #panel { transform: translate(calc(100% - 50px), 0); transition: transform 0.6s ease; } .small #panel { transform:translate(calc(100% - 20px), 0); } #panel.closed { transform:none !important; } $("#slide").on("click", function() { $("#panel").toggleClass('closed'); }) I really want to use Greensock, but I find it strange and a shame that something so easy to do with CSS would require so much code to work with GSAP – unless I'm doing something wrong, of course...