Interesting approach.

When I saw your example on twitter I did wonder to myself why you just didn't create an animation clip which would play back exactly the same no matter what the framerate is. But I guess this is a different application.

An alternative to the damp would be this:
lerp( startValue, endValue, clamp( currentElapsed / timeFrame, 0, 1 ) )

This would then be exact and equivalent to the animation clip example.

I believe this damp is for a different application.... maybe it is best to explain why the two above approaches I suggest are not the best solution?

MathUtils.damp() method has this reference:
https://www.rorydriscoll.com/2016/03/07/frame-rate-independent-damping-using-lerp/

So damp is an easing function?

const easeDamp = (lambda, t) => 1 - Math.exp(- lambda * t);

It's quite similar to easeOutExpo:

const easeOutExpo = (t) => -Math.pow(2, -10 * t) + 1;

If you add the lambda smoothing param and raise to the power of Math.E instead of 2 it becomes:

(lambda, d) =>  -Math.pow(Math.E, -lambda * t) + 1;

Which can be written as:

(lambda, t) => 1 - Math.exp(-lambda * t);

Looking into this a bit more, it seems like there are two ways lerp is being used. To lerp/damp between a and b, you can either:

1. pass in a time parameter t in range [0,1]. With t=0 lerp will return a, with t=1, lerp will return b, but neither a nor b get modified.
2. Pass in a delta time parameter dt. In this case, in each step you need to set a = a + x where x is calculated by lerp with the given easing function (the current Vector3.lerp method works this way).

The second case will work well with the damp easing function 1 - Math.exp(-lambda * dt), because in that case you can put in any dt > 0 and you will never get a value greater than b. I guess that is the magic of damp and it's pretty cool actually. However, I am not fully convinced there's any reason to add new methods everywhere to achieve this - lerp with damp/exp easing will work fine since the term lerp is commonly used for both of these cases. See the main answer in this SO post - at least in Unity, what we are calling damp they seem to simply call lerp.

On the other hand, if many people do think it's worth adding VectorX.damp methods (and maybe `Quaternion.sdamp and others?) then I don't have any particular objection.

Note that the requirement to modify a when using dt is assumed in the definitions here:

https://github.com/mrdoob/three.js/blob/master/src/math/MathUtils.js#L68-L80

It should probably be spelled out somewhere. There's no reason why you can't use dt in lerp and t in damp but you do need to know about this requirement.

Yeah... I don't think lerp() was/is supposed to be used to animate.

For these kind of use cases I'd rather rely on tween.js. Although I just noticed very few examples use it these days... The CanvasRenderer examples used it more.

Yeah... I don't think lerp() was/is supposed to be used to animate.

Interesting. There exist so many good JS animation libraries that adding this in three.js does seem a bit like reinventing the wheel. So we could remove all the damp stuff and recommend people to use another library for animation? Pretty much all JS animation libraries support custom easing functions so you can pass in damp easing to get this result with Tween.js or another library.

@RenaudRohlinger what do you think about opening PRs to add damp easing to Tween.js/Popmotion/React-Spring etc. instead of three.js?

I totally understand and agree @looeee. I will close this PR here and try to come back with this kind of feature somewhere else 👍 (most probably in the react sphere 😬 )