11–20 of 26 posts
A very interesting topic, but I'm a bit disappointed by the article. None of those animations use a physics engine at all… Seems like a part 2 with more complex animations would be needed.
[1] http://research.microsoft.com/apps/pubs/default.aspx?id=1917...
There was a great article on exactly this subject some time ago on HN, but I can't find it right now... The examples were also a lot more compelling than in this one. If someone can find it it would be great!
Do you mean Verlet.js?[1] Note that box2djs is also very capable[2], and has been around for years (it is port of Erin Catto's great work on Box2D[3]). [1] http://subprotocol.com/2013/04/18/introducing-verlet-js.html [2] http://www.jeremyhubble.com/box2d.html [3] http://box2d.org/
http://themeforest.s3.amazonaws.com/74_jquery/jquerygravitys...
doesn't the quadratic timing function pretty much simulate gravity given the right coefficient, and i suppose pixel pitch? http://themeforest.s3.amazonaws.com/74_jquery/jquerygravitys...
A very interesting topic, but I'm a bit disappointed by the article. None of those animations use a physics engine at all… Seems like a part 2 with more complex animations would be needed.
I was disappointed also. I wrote up a (unpublished) paper [1] on this topic once; the gist is that physics presents both an opportunity and a huge challenge for UI. [1] http://research.microsoft.com/apps/pubs/default.aspx?id=1917...
doesn't the quadratic timing function pretty much simulate gravity given the right coefficient, and i suppose pixel pitch? http://themeforest.s3.amazonaws.com/74_jquery/jquerygravitys...
The problem isn't in timing functions. It appears whenever the "distance" involved in a transition is dynamic (rather than specified by the designer/developer).
could this become the next incarnation of skeuomorphism?
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.
In terms of UI animation the most sensible thing to use is Euler Integration (pronounced "oiler").
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.
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).
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.
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.