Animating with physics instead of a timing function | Hacker News Reader

Animating with physics instead of a timing function

taybenlor.com

52 pointstaybenlor24 comments

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...

Thanks for the paper, will read into it later todady as this is a very interesting topic. :)

Yeah exactly, I felt the same. Was hunting for a link or next part to actually see an example using a physics engine..

Uh no. This is completely wrong.

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.

Sorry, I'm not quite sure what you're saying is wrong. I understand your point about physics engines perhaps being the wrong tool here, and I can see that. But the main focus was on how the standard tooling for UI animations is incapable of modelling movement with dynamic "distances" (I put distances in quotes because you could be transitioning colour, height, scale or any other attribute of the object).

The solution presented is incorrect. I can't explain it any more than what I already said.

While he is correct about the fact that standard tooling doesn't deal with "distances", he must at the same time give the right solution.

By the way, another more direct way to get it right would be to solve S=D/T for T and hand that to the UI framework. I'm not sure what language/framework he is using but here is the general idea:

speed = 10; start = 0; end = 100; time = (end - start) / speed;

circle.left = start; animate duration: time { circle.left = 100 }

Which in itself has very little to do with a physics engine, but won't result in a customer logging a bug about how things are behaving strangely on their 120hz monitor.

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 something, but I'm not sure what that is.

TL;DR: If a transition changes values that are dependent on dynamic user input you get an unrealistic effect where small differences take as long to transition as large differences (because transitions usually have a fixed duration).

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

It only seems to work in Chrome, but the example isn't all that compelling.

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).

a bit related, i remember a couple years ago complaining that jquery's "slow" and "fast" as shorthands for preset durations was misleading because when animating on a wide screen, "slow" ends up being quite fast compared to a narrow screen width. you are never really defining the animation rate, as was implied. this is of course due to the fact that everything is based on a fixed duration being passed into the supplied easing function.

Exactly. In a certain way, you could call jQuery UI effects a very limited physics engine.

I don't think the author is saying everyone should use a physics engine now. I think he means that we should use real-world physics as a guide to making more realistic animations, be it with a simple effects library or a full-fledged physics engine.

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.

You're right. I went overboard with my conclusion, the intention was to focus attention on the fact that using a single tool results in lots of similar results and to highlight the flaws in that tool. There are plenty of other tools we could use, not just the one.

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/

I think parent was referring to more on the role of a physics engine in UI, not on physics engines in general. There are plenty of those, but how many UI toolkits are provide real physical animation? As in....the infamous TAT Foldout UI Demo:

https://www.youtube.com/watch?v=FtR_zA9elrM

If you manage to find it, I'd love to read it :)

"Instead we should imitate reality with what we've learned from reality."

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.

Reply on news.ycombinator.com