You wouldn't really need an incremental force: a step-function force (first backward for some time steps, then instantly forward) will still produce a continuous velocity curve.
true! I suppose you'd risk getting some oscillations in the anticipation depending on the scale of the force, but that could be desirable, or might not happen if the scale is small enough, and certainly makes the math a little easier
You can trivially calculate the time-to-peak overshoot using the closed form equation. It’s the first (0-indexed) zero of the velocity response, i.e. happens at t = (pi / scale)
And obviously it would only apply for the underdamped case.
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.
Thanks! From your article, you might not want/like my library since it's based on a single easing function. I used a cubic function to find out the interpolation values, and the derivative to make sure it's always smooth. The equation looks like this, it's on the source code:
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?
It circles around the point without ever reaching it. Each section seemed like it was missing the obvious. "To me" meaning that was my personal impression.
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.
It didn't seem unreasonably deep at all. It was long, sure, but it seemed to only scratch the surface of the topics it was discussing. That was sort of my point in bringing up the css function - it is itself incredibly bare-bones, but just describing it's usage would have covered more ground imo.
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…
By "CSS version" I'm assuming you mean cubic-bezier [1], which definitely does not solve all the author's problems. For example, you cannot use it to create their third example (easeOutElastic), nor many of Apple's kinematic easing functions or the feedback control. [1] https://developer.mozilla.org/en-US/docs/Web/CSS/easing-func...
Yes, you can't use it to create those other functions, but you can use it to fulfill the authors purported goal in using those other functions. It also solves the deficiencies the author highlights in those other approaches. You could of course point to deficiencies in it and seek to resolve those deficiencies, but that wasn't how the article was structured.
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.
It didn't seem unreasonably deep at all. It was long, sure, but it seemed to only scratch the surface of the topics it was discussing. That was sort of my point in bringing up the css function - it is itself incredibly bare-bones, but just describing it's usage would have covered more ground imo.
"Unreasonably deep" is a relative term. Certainly deeper than I care to go. But sure, it could be unreasonably deeper.
Every time I have used animation my approach has been to treat it as frosting to be used sparingly. As such I would be much more attracted to simple/supported modes (that someone else will be interested in keeping functional) than I would be to obsessing over physics realism. But I am also a UI caveman with no taste, so there's that.
As an engineer I'm attracted towards the PID based one, but also wary of the amount of CPU cycles used just for a little animation. It seems like overkill, for some reason.
I don't imagine stepping through the ODE with finite differences at the same time step as drawing should be very expensive, essentially it's a handful of sums and products. In fact, using a closed form solution with an exponential is probably more expensive.
You're right, it's not that expensive! The main limiting factor for me is that not all animations play monotonically forward in time. I'm also interested in using these in animation software where you have a timeline and can seek anywhere. So a closed form is helpful in handling that case too.