Smooth Damp

[msklywenn]

This PR adds a smooth_damp function, useful to have a value gracefully reach a (moving) target over time.

It's from Game Programming Gems 4 and it is very similar to the one used in Unity. (They have an extra max speed parameter)
https://archive.org/details/game-programming-gems-4/page/95/mode/2up

Example:

#[derive(Default)]
struct PlayerMove {
    smoothed_input: Vec3,
    smoothed_input_velocity: Vec3,
};

// ...

        let (pos, vel) = Vec3::smooth_damp(
            player_move.smoothed_input,
            raw_input,
            player_move.smoothed_input_velocity,
            0.15,
            time.delta_seconds(),
        );
        player_move.smoothed_input = pos;
        player_move.smoothed_input_velocity = vel;

[msklywenn]

I added a max speed version and fixed code duplication with private macros

[NathanSWard]

You should probably write some test cases in a test module #[cfg(test)].
While I believe your implementation is correct, we should really start having tests for new features we add to bevy.

[msklywenn]

Yup. Usually math functions are great candidates for tests. However, I've been scratching my head since the beginning and I have no idea of a good test for this. The function is usually used iteratively... Any suggestions?

[NathanSWard]

IMO returning structs > return tuples.
Having a struct makes it much clearer what each value is and prevent bugs where someone accidentally switches .0 and .1.

So having this return something like

pub struct SmoothDampResult<T> {
    smoothed: T,
    velocity: T,
}

would be much clearer and prevent some user-end bugs.

[msklywenn]

At the moment, rust doesn't support tuple destructuring assignment (rust-lang/rust#71126).

But in the future, I expect users to call the function this way: (obj.pos, obj.vel) = smooth_damp(obj.pos, target, obj.vel, 0.1, dt); That's the only reason I wrote it this way.

If I were to use a SmoothDamp structure, I would use it as input too, but that's less friendly. It would prevent smoothing the translation of a Transform while keeping the velocity in another component, for example.

The last option would be to make the velocity input &mut, like C/C++/C# version do, but I fear needless lifetime issues and I like the function being pure...

[NathanSWard]

Input parameters via &mut are not a good option IMO.

I would still argue for the struct return value since you can do something like this:

        let SmoothDampResult { smoothed, velocity } = Vec3::smooth_damp(
            player_move.smoothed_input,
            raw_input,
            player_move.smoothed_input_velocity,
            0.15,
            time.delta_seconds(),
        );
        player_move.smoothed_input = smoothed;
        player_move.smoothed_input_velocity = velocity ;

But I would leave this decision up to @cart 😄

[mockersf]

Is Smooth Damp a special case of lerp / easing / tweening?

[msklywenn]

Is Smooth Damp a special case of lerp / easing / tweening?

It's easing but it's iterative, ie. target value can change over time. You can even have several targets with different smoothing values sharing the velocity vector.