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

I'm Unsatisfied with Easing Functions

davepagurek.com

Post reply on HN
Print view View original

21–30 of 88 posts

Re: I'm Unsatisfied with Easing Functions

#21

Post by bsimpson »

> maybe I can start by just writing up my rant, and maybe someone else will read this and find a Research Project in here and will make the time before me

This is one of the things I find fascinating about Bret Victor. In the early 10s, he was giving a lot of really influential talks on creative coding. Someone asked him what his motivation was. He essentially said that he gives his ideas away, because he wants to live in a world where they exist. It's easy enough to build enough of a demo to give a talk, but he wanted someone else to do the legwork to grow it into a full project.

Re: I'm Unsatisfied with Easing Functions

#22

Post by pahgawk »

EsportToys wrote: post #6

Closed-form (non-iterative) PID solution: https://www.desmos.com/calculator/mu80ttc9aa function sprung_response(t,pos,vel,k,c,m) local decay = c/2/m local omega = math.sqrt(k/m) local resid = decay*decay-omega*omega local scale = math.sqrt(math.abs(resid)) local T1,T0 = t , 1 if resid 0 then T1,T0 = math.sinh(scale*t)/scale , math.cosh(scale*t) end local dissipation = math.exp(-decay*t) local evolved_pos = dissipatio…

This is good! Although I'd also say that initial velocity doesn't quite cover what I was talking about in the post -- even anticipation arguably can start from 0 velocity, accelerate backwards, decelerate, then accelerate in the opposite direction. Imo, any sudden change in velocity should by default be avoided (there are always valid uses where breaking that expectation is good, but I'd want it smooth by default.)

That could possibly be done by incrementally changing force to move it back first, then forward, or to model this as a PD controller following an input with some baked in reversal before moving forward. That can still be closed-form (state response to a known input will be; Laplace transforms can help there), but still would need a bit of effort to model and tune to look right.

Re: I'm Unsatisfied with Easing Functions

#23

Post by shermantanktop »

bsimpson wrote: post #21

> maybe I can start by just writing up my rant, and maybe someone else will read this and find a Research Project in here and will make the time before me This is one of the things I find fascinating about Bret Victor. In the early 10s, he was giving a lot of really influential talks on creative coding. Someone asked him what his motivation was. He essentially said that he gives his ideas away, because he wants to li…

That runs counter to conventional wisdom about patents: very few ideas are worth protecting, because they have zero value until they have been built into something of value in the real world.

And most builders are most passionate about their own ideas. An idea “gifted” from someone else may actually have negative value.

Re: I'm Unsatisfied with Easing Functions

#24

Post by pc86 »

nilamo wrote: post #12
bhk wrote: post #8

Oscullation/"anticipation" in transitions is so gimmicky and cartoonish. Living things don't move like that, and mechanical things don't unless they are broken, chintzy, or poorly designed (underdamped).

Sure they do? When people do a standing jump, they first crouch lower to the ground. An arrow is pulled back on the bow before fired. A ball pushed uphill will roll uphill before stopping and rolling downhill.

Eh, sort of. You do that if you're working out, because you're trying to maximize performance.

Most living beings aren't trying maximize performance, they're trying to maximize survival. That crouch gives away that you're about to jump, and it allows prey to avoid you more easily or predators to adjust their attack to counter for it. A rabbit trying to get away from a predator simply bounds away in its given direction without giving away what its doing.

Re: I'm Unsatisfied with Easing Functions

#25

Post by shermantanktop »

f33d5173 wrote: post #7

To me this article is ridiculous bcause the first thing I think of when I hear "easing function" is the css version of that concept, which seems to solve all the authors problems? The css easing functions are weirdly limited, because they consist of a single function that takes 4 parameters, then a bunch of specializations of that function. There are great websites on the internet for configuring those parametere tho…

I read the article as an unreasonably deep dive into something that few people care about as much as the author. I certainly don’t, but that’s what makes it good. That’s perfect for HN.

Re: I'm Unsatisfied with Easing Functions

#26

Post by pahgawk »

thomascountz wrote: post #14

The section on feedback control reminded me of procedural animation where you don't calculate the velocities and positions directly; instead the animation is a consequence of constraints and a target. I took your PD controller concept and added anticipation using two targets: the original mouse target, and an "anticipation" target set proportionally based on the distance from the point to the main target[1]. This als…

Author here! Nice, thanks for taking the time to create that demo! I also like the look of commenting out `vel.set(0, 0)` when the anticipation target is reached, as it has less "snap" between velocities. Although if you keep velocity the same, now it'll go a little farther than the anticipation target. So maybe if you wanted to have a specific distance of anticipation (I think something an animator would reasonably want to do), one could do some math to figure out where to place the target position so that by the time it decelerates to 0, the distance is the real anticipation distance.

Re: I'm Unsatisfied with Easing Functions

#27

Post by pahgawk »

franciscop wrote: post #20

I also didn't like when a new easing happened _while_ another easing was happening, which often felt very jerky. Had to do a bunch of calculus (derivatives) by hand and wrote a small library for it in JS: https://github.com/franciscop/ola Note: ola means (sea) wave in Spanish

Thanks for sharing this library! Author of the post here, I'll definitely check out your implementation.

Re: I'm Unsatisfied with Easing Functions

#28

Post by ajkjk »

f33d5173 wrote: post #7

To me this article is ridiculous bcause the first thing I think of when I hear "easing function" is the css version of that concept, which seems to solve all the authors problems? The css easing functions are weirdly limited, because they consist of a single function that takes 4 parameters, then a bunch of specializations of that function. There are great websites on the internet for configuring those parametere tho…

how would any of that make the article ridiculous?

Re: I'm Unsatisfied with Easing Functions

#29

Post by ajkjk »

imo there just need to be a few more default easing functions, the standard ones aren't quite natural enough. There must be a standard curve equivalent to the "human pushing/pulling an object from A->B" function that would actually look natural. EaseIn/EaseOut/etc is never quite it; human motion has a bit of higher-order feedback used to regulate it. Maybe to do with the combination of: all the motion happens via muscular springs, plus, there's a well-trained system that regulates the motion to minimize inefficient use of energy. Whether I jerk suddenly and then stop it, or move it slowly so it smoothly decelerates to the final point, it never looks as mechanical as the stuff you see in code.

Re: I'm Unsatisfied with Easing Functions

#30

Post by fidotron »

nilamo wrote: post #12
bhk wrote: post #8

Oscullation/"anticipation" in transitions is so gimmicky and cartoonish. Living things don't move like that, and mechanical things don't unless they are broken, chintzy, or poorly designed (underdamped).

Sure they do? When people do a standing jump, they first crouch lower to the ground. An arrow is pulled back on the bow before fired. A ball pushed uphill will roll uphill before stopping and rolling downhill.

Those are distinct actions though.

"Anticipation" in character animations is a source of persistent friction between game programmers and animators because if incorporated as part of user/player action it simply kills responsiveness. OTOH being able to see NPCs prepare to do something (like pulling the bow) is incredibly useful.

Post reply on HN