Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Animating with physics instead of a timing function

taybenlor.com

Post reply on HN
Print view View original

21–26 of 26 posts

Re: Animating with physics instead of a timing function

#21

Post by taybenlor »

zamalek wrote: post #19

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 tha…

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

Re: Animating with physics instead of a timing function

#22

Post by Wintamute »

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.

Re: Animating with physics instead of a timing function

#23

Post by taybenlor »

Wintamute wrote: post #22

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 t…

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.

Re: Animating with physics instead of a timing function

#24

Post by bumeye »

leeoniya wrote: post #13

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

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.

Re: Animating with physics instead of a timing function

#25

Post by losethos »

planet of the apes with niggers.

God says...

51:16 And I have put my words in thy mouth, and I have covered thee in the shadow of mine hand, that I may plant the heavens, and lay the foundations of the earth, and say unto Zion, Thou art my people.

51:17 Awake, awake, stand up, O Jerusalem, which hast drunk at the hand of the LORD the cup of his fury; thou hast drunken the dregs of the cup of trembling, and wrung them out.

51:18 There is none to guide her among all the sons whom she hath brought forth; neither is there any that taketh her by the hand of all the sons that she hath brought up.

51:19 These two things are come unto thee; who shall be sorry for thee? desolation, and destruction, and the famine, and the sword: by whom shall I comfort thee? 51:20 Thy sons have fainted, they lie at the head of all the streets, as a wild bull in a net: they are full of the fury of the LORD, the rebuke of thy God.

51:21 Therefore hear now this, thou afflicted, and drunken, but not with wine: 51:22 Thus saith thy Lord the LORD, and thy God that pleadeth the cause of his people, Behold, I have taken out of thine hand the cup of trembling, even the dregs of the cup of my fury; thou shalt no more drink it again: 51:23 But I will put it into the hand of them that afflict thee; which have said to thy soul, Bow down, that we may go over: and thou hast laid thy body as the ground, and as the street, to them that went over.

Re: Animating with physics instead of a timing function

#26

Post by zamalek »

taybenlor wrote: post #21
zamalek wrote: post #19

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 tha…

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.

Post reply on HN