Unfortunately you cannot extend this approach much beyond this simple example if you are writing a physics simulation. There is no known closed form solution, for example, for the famous three body problem, so a some sort of numerical integration is absolutely required. At that point, you should just decouple the numerical integration timestep from the monitor refresh rate, or mandate a refresh rate that will be acceptable to the player.
Game dev here. Hardly any serious game developer uses lerp like that. I prefer a quadratic friction when I write custom friction, ie: a constant force away from velocity, and simply ensure it doesn't go past the zero point. More controllable. Box2Ds friction uses something like v = v * 1/(1+damping*delta_time), which is a good method as well.<p>Keep in mind it's best practice to run your game logic at a constant update rate and render an interpolated state between the current and previous game logic frame, meaning that if your game logic is frame rate dependent, you can still run it smoothly on any monitor.
Alternatively, you could fix your timestep, decoupling your physics from your display refresh entirely.<p><a href="https://gafferongames.com/post/fix_your_timestep/" rel="nofollow">https://gafferongames.com/post/fix_your_timestep/</a>
All the frame rates in this post appears to refer to physics frame rates, but Godot makes the distinction between physics and display frame rates, and have separate callbacks for each:<p><a href="https://docs.godotengine.org/en/stable/tutorials/best_practices/godot_notifications.html#process-vs-physics-process-vs-input" rel="nofollow">https://docs.godotengine.org/en/stable/tutorials/best_practi...</a><p>Because physics frame rate is fixed (configured under project settings), I suspect developers would be able to get away with using the common lerp() formula and not having to worry about varying (display) frame rates.
I think the real problem with the OP's straw-proposal interpolation method is that it's stateless and doesn't need to be. I would instead record the start position, then interpolate along a function F(t) to the end position. F(0)=0, F(1)=1, F'(0)=F'(1)=0 just so the ends aren't jerky. The curve can even overshoot 1 to give the animation some bounce.<p>I'm sure somewhere on the Internet somebody's written down some good choices of curve; hopefully someone else knows what to search for.<p>(I don't know what to do if another change interrupts the first but it's a rare case and can probably be handled imperfectly.)
Don't most modern video games run a physics thread at fixed rate in addition to the rendering one?<p>I remember Quake 3 still having that issue, but that was in '99...
Wouldn't you just want to sample a normalized curve and apply that? What is the use case where you want to use this iterative call, care about frame accuracy, but can't afford curve data?<p>With the explicit curve you have more control in the exact damping, too.
I was bit confused how a formula that depends on a constant frame rate works with variable refresh rate. Then the author commented that you don't need to calculate the quantity that depends on frame rate in code. <a href="https://news.ycombinator.com/item?id=40401211">https://news.ycombinator.com/item?id=40401211</a><p>I'm really lost, but alas have ~0 experience with 3D about 15 years into a career.<p>Ignoring variable frame rate:
1. Doesn't the frame rate depend on the display hardware?<p>2. Can you know the frame rate at runtime?<p>Variable frame rate:
3. What quantity do you use for frame rate for variable frame rates?
Now write the formula in terms of expm1 for numerical stability, and express the constant in terms of “half life” measured in seconds to make it intuitive instead of magical.