Jump to content


Additive animation

Moderator Tag

Warning: Please note

This thread was started before GSAP 3 was released. Some information, especially the syntax, may be out of date for GSAP 3. Please see the GSAP 3 migration guide and release notes for more information about how to update the code to GSAP 3's syntax. 

Recommended Posts



I was just thinking that if I saw this demo a week ago, there is no way I would be able to believe that those animations are just simple linear tweens. It looks like some complicated path following algorithm is being used.


I don't think I'll have time to try this out, but I'm thinking that Carl's challenge to recreate the new Google logo animations would be a lot easier to pull off using this.

Link to comment
Share on other sites

I’m happy to hear you’re interested in additive animation. You might not be so happy as this post turned out a lot longer than I thought.


I developed the technique five years ago and made the feature requests to Apple, which is what brought me here. I actually blogged about GreenSock a couple of years ago, but perhaps I came off as attacking the platform instead of making a proper feature request. [1] (My bad.) As was pointed out in this thread earlier, it is difficult to convey what is happening and why it is beneficial. There are drawbacks as well. It is a powerful but counter-intuitive technique that I hope to explain.


In short, you animate from the old value minus the new value to zero. Animations do not get removed, instead many can run concurrently. The values get added together, to themselves but also to an underlying, non-animated value. When an animation’s duration has elapsed, its effective value is zero and can be removed without side effects. All that remains is the underlying value. Combined with an easing function, it gives seamless blending and beautiful curves.


It lends itself to discrete app state. In simple use cases the developer no longer has to reason about current animated values or quasi indeterminate state, and can focus solely on destination values and layout. Because multiple animations can run concurrently, it gives complete separation of concerns. Animation of an element triggered in one part of your code does not need to know about animations running on the same property triggered elsewhere.


Let’s consider interrupting an in progress animation. The typical way to handle interruption has been to prevent it by completely blocking the UI until the animation is done, or to replace it with a new animation that begins where the previous left off. The former is a complete disaster but prevents visual discrepancy. The latter is an improvement but not without drawbacks. This is CSS transition behavior. Interruption will give sharp sudden angles, or asymmetric timing when reversing an in progress animation, like a hover. (The reverse distance travelled is shorter than the original, but the duration stays the same.) Additive animation provides a solution, and a simple one.


There are other ways to accomplish animation blending. Facebook POP is the most notable, ported to the web in Rebound.js. POP relies on a single animation per property. Interrupting will mutate the animation to include smoothing/dampening. Of course nowadays everyone advocates immutable data. Mutating may not be such a big deal, but does prevent optimization like running on a separate process. But also information gets lost. Unlike additive animation, POP cannot blend two keyframe animations. [2]


Web-Animations also takes a blending approach. At the very bottom of the spec they have a note claiming to have a solution to blending timing functions but deferred it to a later version. [3] Frankly, I will believe it when I see it. I think all blending techniques are overly complex and fall short of desirable behavior. Blending animation duration and easing/timing functions doesn’t make sense to me, and I have not seen any other solutions to blending path or keyframe animations, all of which an additive solution can do easily.


Additive javascript implementations have appeared. Unfortunately they may never see the same performance benefits as native Core Animation, which actually runs the animations in a separate process with a very high priority. Currently Mozilla is implementing what they call Electrolysis (e10s) which will mean Firefox will have separate processes per browser tab, like “Chrome Helper” et al, but still will not compete with Core Animation in terms of performance, because what drives animations gets lumped together with everything else.


Thus I don’t think the Javascript community has yet been convinced, because of availability of these competing techniques and for lack of a performance benefit. Unfortunately they miss out on blending keyframe animations, and running multiple animations on the same property of an object simultaneously.


From an API standpoint, first and foremost is to automatically convert developer input from absolute to relative values. Relative means from old minus new, to zero. A transition for a change from 2 to 10 would instantly set the new underlying value to 10, then an animation from 2 to 10 would be converted to -8 to 0 behind the scenes. When added to the underlying value, the negative value puts the element back to the apparent start value.


When interrupting and reversing the above example animation, say at an animated value of 5.5, the underlying value is instantly changed from 10 back to 2. The second animation’s converted values are from 8 to 0. The previous animation continues to animate to zero, which when added to the new underlying value of 2 does not cause a sudden jump because the second animation puts the element again back to where it started from, this time 10. The animated value can be ignored.


Matrices are more complicated but the operation is concatenate the old transform with the inverse of the new, with zero being the identity matrix. In my opinion, there is no benefit whatsoever to use additive animation without this conversion, or with a destination value other than zero. So I prefer to call it “Relative Animation” and let the additive nature be a private implementation detail.


My experience with GreenSock is very limited, please forgive me if I make statements about it that are not accurate, but two years ago I found its additive/relative functionality is not the same thing that I describe. It does look like GreenSock’s overwrite setting might permit concurrent animations on the same property and element, but I have not tried it out. The documentation does not mention additive. I think all operations can either replace or override any other animations, optionally without destroying previous ones, which could then come back into effect, say, if the previous has a longer duration and the newer ends sooner.


You need to have a strong concept of non-animated vs. animated values. In Core Animation that means model vs. presentation values, and is wonderful. Web-Animations has specified vs. computed values. My concerns about a GreenSock implementation is that its animations seem to be predominantly forward filling. By that I mean when animating an object from A to B, the value persists at B after the animation is complete because the animation is still active and its values still applied. 


A forward filling system can work, and may be required for things like transform rotation. To animate from 0 to 90 degrees (non-additive seems a lot simpler) the way I do this using Web-Animations is to also have a non-additive constant animation, from 90 to 90 degrees that is forward filling and does not get removed. I call them underlying value animations, when toggled they get replaced instantly, while their relative interpolations do not. This complication is not necessary in Core Animation because of its clear distinction of model and presentation values, sadly absent from CSS. This is an implementation detail that probably could be taken care of by GreenSock’s own internal handling of state.


I bring attention to forward filling because there are benefits of animating relative to an underlying value specified elsewhere. The web already has CSS to layout elements. It would become unwieldy to layout only with forward filling animations, in anything but the simplest of use cases.


A developer could position an element via left and top using element.style or the style sheet, then animate its transform for performance. This is easy to do as both the absolute and relative destination values are zero. Paul Lewis blogged about this technique, but his version was not additive and so does not handle interruption. [4] The I_Am_Ralph_T physics animation also animates transforms to zero, and they are interruptible, but not additive (I don’t think). [5] 


A problem with animating CSS laid out elements relatively is browsers will re-calculate layout, but also unfortunately redraw before I have a chance to calculate the deltas, causing flicker. Web-Animations has a single line to fix this, requiring vendors not redraw immediately. [6] Thus, relatively animating floated content is now possible in Chrome but not yet viable in Safari.


I should also point out that getBoundingClientRect gives animated values, which means the developer has to use offsetLeft and offsetTop to calculate non-animated values for relative animation. Using non-animated values is normally a benefit, perhaps not in this case. Having to work around APIs that did not anticipate relative animation is a drawback.


Another feature more complicated animations might need is the ability to copy animations from one element to another. I’m not sure if this is possible now or makes sense with the GreenSock API. The path produced by many additive animations can be complex and hard to recreate. If the developer needs to insert a new element alongside an existing animating one, copying animations can accomplish this. Of course this and many of the features of additive animation can also be replicated by nesting elements.


Drawbacks to additive mostly involve having to deal with an unknown number of animations instead of only one. You would have to track and copy many animations, for instance. In the WWDC 2014 #236 video, it is mentioned that it is hard to “catch” or instantly stop animations. All animations would need to be removed, then a new underlying value set to compensate. I would argue that the true relative pattern is to never remove them, instead permit them to finish. This is a case where a true physics simulation might be superior.


If animations are not removed, very slow or different animation durations could be a problem. It might give expected behavior, it might not, but I tend to prefer short and unchanging durations.


I forgot to mention, physics can be simulated in additive Core Animation or Web-Animations by calculating your own keyframes to give a nice springy effect or wobble, but it can be somewhat simplistic. I find the wobbling usually blends well. Large value changes cause a greater wobble, smaller and more continuous changes, having a smaller delta, barely produce a wobble and do not look bad. But again, this might be a bit simplistic for some. I found that in javascript, scientific notation shows up often, especially when you animate to a value of 0 with a little wobble. CSS cannot parse scientific notation, which would cause flickering, so it needs to be converted.


To calculate keyframes, say for example A, B, C, D, E, F, G, relative conversion means A-G, B-G, C-G, etc. Another neat trick is a solution to rotating matrices. Since you cannot determine intent from a destination value matrix alone, for example if it should rotate 720 degrees multiple times or a combination of flips, the traditional approach has been to use keyframe animations with half rotations, or use a provided special animation function where the developer explicitly says to rotate n times (which cannot be determined otherwise.) Additively this can be accomplished by simultaneously running twice as many half rotations.


I have my own animation framework that is a derivative work of the Web-Animations legacy javascript shim. It is a significant departure from Web-Animations, instead meant to resemble more closely Core Animation’s API, or at least its usage. I do not however recommend people use it for anything other than experimentation as I haven’t implemented tests and make breaking changes on a whim. But I have examples below.


Also, I am very impressed that you were able to figure out additive animation from the slides in that WWDC video, because of the errors. In that picture, the second animation’s duration should be the same as the first, they imply the second is shorter for some reason, from 1.0 second to 0.4. The end time would also be different.


But anyway, there isn’t really an animation API for the web out there that gives me all the tools I would like. The Web-Animations team refused my proposal to implement a property to enable conversion from absolute to relative values. This means in the future there will never be a CSS Transition property that uses relative (or additive) animation, but additive CSS Animation might be possible. My hopes are with GreenSock now!



1. Dissing GreenSock: (No not really. I called it negative delta back then, it is poorly written, and should be no surprise that I did not convince anyone.)



2. POP cannot not blend keyframe animations: (no one can, but me… for now. Maybe you can change this.)



3. Proposed smooth timing function: (Maybe it doesn’t mean what I think it does)



4. Paul Lewis: (FLIP sounds a lot catchier than negative-delta)



5. iamralpht (Sigh. Physics is very nice, I can’t deny it)



6. Changes made within the same task are synchronized such that the whole set of changes is rendered together:



7. Animating floated content, requires Chrome: (click or resize window)



8. Blending keyframe animations !!! (compare single click vs. double click vs quintuple click)

See the Pen YyXLWp by kvndy (@kvndy) on CodePen


9. Chained together animation sequence, requires Chrome: (click)



10. Implicit animation. The blue div uses constant underlying value animations, but is not something I would do unless I had to. More notable is how the orange and purple divs get animated automatically on element.style change, without CSS transitions or explicitly adding animations. They are declared and triggered automatically:

See the Pen meJYEj by kvndy (@kvndy) on CodePen

  • Like 2
Link to comment
Share on other sites

I'm not big into social media, so I'm used to most of my work going unnoticed. This time was different. I wanted people to see this, and it paid off. Early in the morning I saw a notification that said Kevin Doughty liked your pen. I had to do a double take to make sure it was the real Kevin Doughty. Score!!! I hit the mother lode. 


Just look at this. This is what you call a responsive layout!!! 



To bad I have to leave right now. I'm going to have to come back to all this craziness later tonight.

  • Like 4
Link to comment
Share on other sites

Nice Video Blake.. i would be really interested to see how that performed in different browsers like Chrome, Firefox and IE on Windows. Due to the way each desktop and mobile browsers apply these changes over time.Especially on Mobile Chrome and Mobile Safari. With apple and blink WebKit being the most bug filled browsers (chrome and safari), since the death of IE8. One month a feature in the spec is supported and the next month it is not. Where as Firefox will render things according to the spec. Even being the only browser to not render a image GIF when hidden, unlike chrome and safari that will keep the hidden gif image running, even when hidden.


Also i believe the technique Paul Lewis describes as FLIP above, is already done by GSAP automatically.  When it records and stores all the start and end values when it does the various from() tweens. And also when you use tl.progress(1).progress(0) .. so all the calculations and recordings are already taken care of when you play the animation.


Additive animation is definitely very cool. Great YouTube video Blake, Thanks for sharing!

Link to comment
Share on other sites

Yeah, I'm not sure how that would perform in different browsers because on the planet I live on we do not have animated layouts like that. 


You should try and see what kind of stuff you can you can do with relative floating demo. Maybe add in some text and use the splitText plugin to see how it behaves when you drag the box around. I didn't see a examples folder on GitHub, but you could just copy the JavaScript used in the demo to create your own version. He said it will only work in Chrome. I also saw a JSFiddle version of it a couple of days ago, but I didn't save the link. If I come across it again I will fork it.



  • Like 1
Link to comment
Share on other sites

Sorry for being late to the party, guys. Great conversation. 


I'll definitely explore this concept a bit more and think through how much of a rat's nest it might be to integrate into a future version of GSAP. There are certainly things about it that are appealing. 


My two biggest concerns at this point are:

  1. Performance. This approach requires creating and tracking another "source of truth" for the various properties of each target, even when people aren't using additive animations because if at some point they DO create one, the system must have that data ready to tap into. The other thing I wasn't crazy about with additive systems is that it forces at least one more "read" on every property on every update/render. read/write/read/write can be somewhat expensive although we'd avoid using the target itself as the source because that could be horrible for performance (style recalcs). If adding this feature makes the entire engine slower for everyone (even those not wanting to do additive animation), that's a pretty big loss for me. 
  2. Complexity and file size. I don't think this is a super simple thing to just slap into GSAP. It would likely have a pervasive and cascading effect. I'm not sure how much bigger it'd make the files. That'd take some exploration.

Side note: the various overwrite modes came into existence a long time ago and I get the feeling that the only widely used modes are "auto" (by far the most popular) and "all" (or true) and "none" (or false). Does anybody else use other modes? I'm just thinking through if it'd be worth ditching the others and adding a new "add" mode or something. I'd love to hear everyone's thoughts. 


Thanks again for the conversation, guys!

  • Like 2
Link to comment
Share on other sites

Hi Jack.

Thanks for joining in and for considering this in GSAP :-)

Personally I rarely need any other overwrites than the default in TweenLite.


In terms of performance, wouldn't it be an idea to consider forcing overwrite:"add" for properties that should be capable of overwriting in the future - I think that's a fair price to pay for the feature? So you can never start a tween without that overwrite mode and later overwrite with "add", you will need that overwrite mode from the very first tween. In that way you can completely separate the calculation methods, so you don't damage overall performance of the engine. Just an idea.


As for file size, if this could work as a plugin, it would be completely optional to load. But I guess that's hard with something that taps into the heart of the engine?


Thanks to all of you for exploring this and sharing your thoughts. Some great new knowledge here :-)

Link to comment
Share on other sites

You said "consider forcing overwrite:"add" for properties that should be capable of overwriting in the future" - could you explain a bit more? I don't follow. Are you saying the user would provide a list of property names that they want to be additive-able in the future? What would that look like API-wise? 



We could certainly do it as a plugin but that'd require that you always segregate things into that plugin's property, like:

TweenLite.to(.... {additive:{x:100, y:300}, ease:Linear.easeNone});

And it would also mean that you couldn't do an additive tween of properties that weren't created as additive to begin with. For example, this wouldn't work:

TweenLite.to(... {x:100, y:200});
//then later...(this would NOT work because the first tween wasn't registered as additive):
TweenLite.to(... {additive:{x:300, y:400}});

See what I mean? It also gets messier when there are interacting plugins, like if you try animating a CSS property additively because both the CSSPlugin and AdditivePlugin would have to interplay. Not impossible, just more challenging and code-heavy. We already do this with a few other plugins like BezierPlugin. 


To make it more pervasive and flexible, it'd have to be baked into the core but that'd likely involve some performance tradeoffs. 

  • Like 2
Link to comment
Share on other sites

Hi, actually your example is just what I mean. You either use additive or not - you can't mix it. It's not that pretty I know, but it's one way to go :-)

But it would be nicer to have it baked in of course.

Link to comment
Share on other sites

I personally only use either auto, all, or concurrent overwrite modes Jack :)


I wonder if you could make a poll of the overwrite modes users use to get a better idea?

Link to comment
Share on other sites

Thanks for considering this. OSUBlake you are too kind.

First I have to mention the animated text is a native Mac app, and I don’t mean React Native. It suffers from an awful class inheritance hierarchy, and poor handling of ligatures or text input with anything other than Western style glyphs. I never posted the code and probably never will. It is a good example of the need to copy animations. (Line fragments are continuously split and merged.) It looks like in the future we might get very robust glyph metrics that could make this possible in a browser, with HTML5 canvas and one of the new Houdini specs.
Layout thrashing could be a deal breaker. The underlying value could be affected by className change or programmatic style sheet changes. I don’t know a solution other than either constant style recalcs or caching the value at the start and ignoring changes coming from elsewhere. Not good.
Cluttering up an API is nearly as bad as negatively impacting performance. Unfortunately I have to mention one more point that I did not stress enough before. There is value in automatic conversion from absolute to relative values for animating like (implicit & declarative) CSS Transitions and (explicit & imperative) CSS Animations. But there is also a use for additive without that conversion, for those like CSS Animations.
For instance CSS Transform rotate3d has arguments for both amplitudes and the angle. It is unlikely that someone would want to animate all arguments to zero. In those cases I do the conversion to relative values manually. 
One neat thing is that if someone does manual conversion but then uses a function that also does this, it results in the same values. From 2 to 10 manually converted into from -8 to 0, if converted a second time is still -8 to 0. That would break things though, if the inputted (absolute) destination value is used as the underlying value.
There are also uses for animating from zero to zero. The scaling done in this next video kind of does that, but uses an excessively complex custom easing. To get the magnitude of the scaling right, the easing function is what actually goes from zero to zero, instead of from zero to one. It’s weird, and probably a bad example. I think it could be done better by compositing simpler animations together:
This is a better example. At least, it looks cool but may not be the best to peruse. It gets the idea across what you can do with two animations running simultaneously:
They are both for iOS. I will hopefully get around to making them simple DOM or canvas examples, one of these days.
That animating floats jsFiddle is not recommended. It uses Web-Animations and an earlier version of Hypermatic when it was a jQuery plugin, but I do not recommend even looking at it. My javascript skills have improved in the last two years, somewhat. I prefer:
It seems many of my examples have broken. I would avoid anything with a file name prefixed with negative-delta. They can be found here:
Link to comment
Share on other sites

Kevin, I really appreciate you taking the time to explain how this works. Your second post really helped my understand how relative animations work. I must say that you are an absolute genius!!!
The whole negative delta thing was confusing to me because I wasn't doing relative animations in my previous demos. It wasn't until I started working on recreating your floated content example that it hit me… and it hit me hard. I was floored. It's so simple and obvious now. 
So here's the demo I recreated. Click anywhere and start dragging the box around to resize the container. Go crazy with the resizing. Click back and forth between the far left and far right side to create an interesting swinging effect.

See the Pen zvpEMg?editors=0010 by osublake (@osublake) on CodePen


Pretty cool, right? There's a lot of stuff going on, so there must be a lot calculations taking place. Nope! This is what floored me. If additive animations were a part of GSAP, you could create that entire animation by calling one simple tween on each element.


TweenLite.from(element, 1, { x: lastX - element.offsetLeft, y: lastY - element.offsetTop });


That's it! You could do same thing with a flexbox layout. I've never seen a flexbox layout animation that didn't involve a bunch of calculations and/or cloning of elements. Now we know it's possible to do using a very simple tween.
I was curious how text would work so I dropped in the SplitText Plugin. Now this could make for some really interesting animations. 


See the Pen mepBam?editors=0010 by osublake (@osublake) on CodePen


When it comes to the different overwrite modes, I have never used this feature, so I'm only familiar with "auto".
I understand that this would increase complexity and file size. If it makes the file size too big, couldn't this just be a TweenMax only feature or maybe an optional utility class that could hook into the engine?
Concerning performance, I think you should look at the overall animation and not just GSAP. While it's true that the engine will have to do more work, other things can be simplified so the overall performance impact might be negligible in some cases.
For example, look at the animations used in these waves or the GreenSock cape. They're both really nice, but require some expensive calculations to be performed on each update. You could simplify both of these animations by animating a set of points in a zig-zag pattern. The additive animation process will blend the movement into a nice smooth motion. So instead of doing trig calculations on each update, all you would need to do is apply those points to a catmull-rom spline and it should look pretty close to a sinusoidal wave.
I haven't tested this, but I'm pretty confident that several additive animations running at the same time would perform better than doing a bunch of trig caclulations on each update. I know that animating waves is not something you typically see, but it does illustrate how additive animations could possibly improve performance by reducing the overhead somewhere else.





GreenSock Cape:



Floated boxes: 



Split text:



Catmull-Rom Solver:



  • Like 4
Link to comment
Share on other sites

Great input, Blake. And I want to be clear that I do like aspects of this additive stuff a lot and it's actually very similar to something that I've been contemplating for months but I haven't quite figured out how I can implement it yet. 


It probably can't just be a TweenMax thing, no. It's just way too foundational - it would likely affect every single plugin too. This is no easy task to just slap into TweenMax and make it work properly across the board. That being said, I'd love to find a way to make something work. I just need time and focus (two things that are hard to come by lately). 


As for the performance thing, while it's true that it may be a bit less CPU-intensive to use that technique with the flapping cape (not sure - haven't tested), I'm pretty confident that for 95%+ of the animation work that most people do, it'd be slower. But it is tough to know how significant it'd be without testing. So I don't want to claim with 100% certainty that it'd be "bad" performance-wise. There are  a lot of ideas bouncing around my head that could affect this stuff. Maybe I can figure something out that'd make everyone happy. But again, this is way more complex than just popping out a plugin, so it'll take some time. 


Thanks again for keeping the conversation going and sharing your experiments. Love it!

  • Like 1
Link to comment
Share on other sites

The whole sine wave thing is kind of interesting. I discovered it by accident, but that's what led me to make that

See the Pen dYVNYd by osublake (@osublake) on CodePen

. And yes, I agree that most animations won't take advantage of this. It's definitely better suited for animations that are created in response to some user interaction.


Just something to think about. Now that I have a better understanding of how this works, I would create my additive animation class based around a timeline to make it easier to manage. I know this doesn't fit into the current API, but for my demo purposes I would set it up where you add animations to the same instance. Maybe something like this.

var tween = new AdditiveTween("#element");

// Just add animations to the instance
tween.to(1, { x: 100 })
     .from(1, { y: 100 });

// Later on...
tween.from(1, { x: -100 });
Link to comment
Share on other sites

  • 6 months later...

Hi, I don't mean to spam the forum, but I recently finished a project where I implemented an additive animation approach. It was a bit difficult, but really worth the effort. Thanks to OSUblake (and the rest of you in this thread) for creating some great examples to learn from.


This is the site: http://www.beoplay.com/landingpages/portraits

Try scrolling quickly and you will see the background image animations (zoom and pan) blend into each other, instead of overwriting (which would be normal behaviour).

  • Like 4
Link to comment
Share on other sites

Nice work, Michael! Seemed silky smooth to me. 

  • Like 1
Link to comment
Share on other sites

  • 2 weeks later...

@Michael Vestergaard,
Thanks for the update! I was wondering if you were still looking into this.
That's a very beautiful site, and those animations are crazy! It almost makes me feel like I'm on roller coaster heading into a high speed turn. Can you turn the additive animations off? I'd like to see a side-by-side comparison. But it's nice to hear that I'm not the only one that had trouble figuring this stuff out. Are you animating everything to 0 using reversed values? That was definitely the hardest concept for me to wrap my head around.
I'm still very much into this, and have been looking out for any new projects or examples. Interestingly enough, this thread is probably one of the best sources available. I just googled "additive animation", and this thread showed on the first page alongside some high-end game engines. Probably because of all the stuff Kevin posted. Every time I read his stuff I learn something new.
I just found out a couple of weeks ago that additive animations are part the of Web Animations API spec. It's not available in any of the current builds, so I have no idea how it actually looks/performs. Regardless, I'd much rather have this built into GSAP as I also do a lot of canvas animation, so Web Animations are of little use there.
If you make anything else, don't be afraid to share it with us!

  • Like 1
Link to comment
Share on other sites

Thanks for the feedback :-)

I can't turn the additive animations off on the site. But I made

See the Pen mVzdNw by iltp (@iltp) on CodePen

a short while ago.

I based much of my code on your examples (thanks a lot for those). I did some modifications, but the concept is the same.

The only thing making this hard to duplicate for other projects, is the hardcoded parameters (x, y, scale) - it would be nice to have all parameters excepted and even some parameters without the additive approach. But that's a nice weekend project when I have the time!

  • Like 1
Link to comment
Share on other sites

Great topic and lovely site  @Michael Vestergaard! I'm going to experiment with this later on tonight. As @OSUblake mentioned, I also found this topic through Google, while looking if GreenSock supported additive animations.


Link to comment
Share on other sites

  • 3 months later...

I finally found some additive animation demos using a legacy version of the Web Animations API. Very interesting seeing how they are composed, much like a timeline.



One thing I found really interesting is how you can animate rotation using top and left (from slide 18).


  • Like 3
Link to comment
Share on other sites

  • 2 years later...

This is such an awesome read guys, props to all of you.


Miles away from what I can do, but I'm super inspired reading through all these examples.



  • Like 2
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.