Animating with physics instead of a timing function

A very interesting topic, but I'm a bit disappointed by the article. None of those animations use a physics engine at all…<p>Seems like a part 2 with more complex animations would be needed.

Uh no. This is completely wrong.<p>Ever tried to play really old games like Worms 1 on anything faster than 100MHz? They are "framerate locked" which means that a higher framerate makes everything go faster. So if you used that function on a 120hz display everything would run at twice the speed (assuming it's designed to run on 60hz). This is why things like Dos Box let you run at a lower emulated CPU frequency: so that you can slow things down so that these games are playable.<p>In terms of UI animation the most sensible thing to use is Euler Integration (pronounced "oiler").<p>Euler Integration is based off of Distance = Speed / Time. Basically what you need to do is remember the "last time" the function was called (using a high resolution timer) and find the difference between that and the current frame. This gives you the "Time" in Euler Integration, your "Speed" should be a fixed constant (e.g. 1 pixel per second). Then simply add Distance / Speed to your current X value.<p>Things git a tad bit complicated to ensure that you don't "overshoot" your target position, but it's nothing simple high-school algebra can't solve (that's the nice thing about Euler Integration, it's all high school Mathematics and Physics).<p>Techniques like ease-in/ease-out are easy to do (using the difference in distance between the current point and starting/ending points use base your speed off of that), all using high school algrebra.<p>I wouldn't bother with Verlet or Runge-Kutta: it is just UI animation after all - you aren't going for very accurate results like games do. "Real" physics engines also have the problem of not being able to guarantee deterministic results.

I'm not sure I buy the premise, but that may just be a failure in the explanation. The author claims it's "more real" but provides little in the way of an explanation as to why this is so. It doesn't feel any more "real" to me. I feel like the author is trying to explain <i>something</i>, but I'm not sure what that is.

Interesting premise. Unfortunately, the only animation that worked for me was the tweening one.

doesn't the quadratic timing function pretty much simulate gravity given the right coefficient, and i suppose pixel pitch?<p><a href="http://themeforest.s3.amazonaws.com/74_jquery/jquerygravitysource/index.html" rel="nofollow">http://themeforest.s3.amazonaws.com/74_jquery/jquerygravitys...</a>

This is wrong. The "feel" of an animated interface is an entirely creative/artistic/subjective thing, and its overall success is down to the sensitivity of the animator, not the underlying mechanism. There's always going to be a place for both time and speed based simple animations, as well as animations based off easing equations, physics engines and everything in between. We use whatever feels and looks right for the job at hand. To say that we'll achieve better results by stopping using duration/easing equations and only using speed is overly simplistic and, I'm sorry to say, rather naive.

There was a great article on exactly this subject some time ago on HN, but I can't find it right now...<p>The examples were also a lot more compelling than in this one. If someone can find it it would be great!

"Instead we should imitate reality with what we've learned from reality."<p>could this become the next incarnation of skeuomorphism?

By the looks of part one I don't think part two will use anything more complex than easing functions with a maximum movement speed…

Good start but I'd love to see some more complex examples.