Math for Curves and Interpolations (Lerp and Callmul-Rom)

[lassade]

Required by #1429, adds curves and a Lerp trait used by the animation system in the bevy_math crate;

Notes

• I didn't know what lerp algorithm was used by Vec2, Vec3 and Vec4 so I used one with precise t == 0 and t == 1
• lerp is by default clamped (but there is a lerp_unclampled)

Missing bits, (non block)

• Handle and HandleUntyped should implement lerp using a step function
• Test CurveVariable behaviour

The new Color definition make lerping and a color curve really complex and impractical (please join the discussion here), It's is some what related but doesn't block this issue;

[inodentry]

Have you looked at the bevy_easings crate as prior art? Would anything from there be an inspiration / to be included into bevy?

https://github.com/mockersf/bevy_extra/tree/master/bevy_easings

Also, would your animations work obsolete bevy_easings? It would be great if the use cases that crate offers could be provided by bevy internally.

Note that bevy_easings provides quite a rich selection of interpolation functions. In particular, I think having a "quadratic in/out" interpolation function would be useful, it's a common one.

[mockersf]

In the scope of #1429, this is much more general than bevy_easings.
For interpolation functions, they all at their core use the lerp method, so once it's available it gets trivial to add all the functions you want

There is commented code in this PR, should it be removed?

About the TODOs, do they need to be fixed in this PR or leaved for later?

Also, some of the doc comments don't sound completely right to my non-english native ear, could someone check?

[lassade]

What comented code? I wan't to keep the Color stuff around because I know we are going to need them;

Not sure what TODOs, but I want to keep them for later, otherwise they will be forgoten;

Can you point out the comments that sound strange?

Note also that CurveVariableLinear and Interpolation are still a bit rough

[mockersf]

I added a few comments on commented code and doc

Not sure what TODOs, but I want to keep them for later, otherwise they will be forgoten;

There are 8 TODOs, will you address them in a next PR? Or need some help with them?

[lassade]

Added 2 more functions in the Curve api to move common functions from curve specific impl to the trait impl;
Added a resampling function that I wrote a while back

[alice-i-cecile]

Alright, I did some more digging: Rust's native solution for this is faster than the approximate solution because inverse square root has a dedicated instruction these days. See: https://stackoverflow.com/a/59082210/3234149

IMO this function should be cut completely and its usages should be replaced with sqrt().recip().

[lassade]

Good catch

[lassade]

Do you know how the intrinsic rsqrt + a single Newton-Raphson iteration compares with the 'carmack' method?

In that same thread I found this: https://stackoverflow.com/questions/31555260, so I compiled a few possible methods here https://play.rust-lang.org/?version=stable&mode=release&edition=2018&gist=ddc10be842400c95b81a0c5fba218da6;

If my memory is not failing me, in a old bench I found that sqrtss as a very hot instruction and that made me use the carmak method, I will have to double check that ...

[james7132]

Small note: While sqrt and 1.0/x are guaranteed under IEEE-754 2008, implementations at the hardware level may or may not be compliant. My particular game I'm working on requires animation to be in the networking simulation hotpath, and cross-platform determinism is mandatory, something that may not be uncommon to see across other networked games too. If we are going down the route of sqrt().recip(), could we use libm::sqrtf here under a feature flag? glam already has a feature flag for it, so we could pass the feature flag through for ease of use.

The 'carmack' method here does not have this issue and should be consistent across platforms.

[alice-i-cecile]

Yeah, I think we're going to need to do our own modern benchmarks here to get a firm answer on what's correct for this context.

The note on determinism is important; the approach James suggests seems very reasonable.

[lassade]

I think in doing _mm_rsqrt_ss with a fallback to quake3 method for non x86 or libm / no_std but I'm not sure if the aligment requiriment will be a problem, expecially when called by the consumer code, on the nlerp side I can make things rigth I think ...

[lassade]

@james7132 did you checked the lib impl for sqrtf here? It don't look like it's cross-plataform deterministic

[lassade]

I submitted a revision for this function, by the looks of it the compiler can optimize the re-alignment instructions so it should not be a problem

[james7132]

It doesn't look like it at a first glance and it's difficult to tell if it actually produces the same output as the intrinsic with sse disabled. If it does, we may need to reevaluate this approach to achieving cross-platform FP determinism.

The approx_rsqrt implementation here, however, we for a fact know does not produce the same bit-for-bit results between the two implementations given the error difference seen from the benchmarks.

[lassade]

I suggest you to resample the curve animations, that way you can mitigate any differences between cross plataform hardware

[Weibye]

The examples/animations/smooth_curves.rs needs an entry in the examples/README.md

[alice-i-cecile]

@lassade, can you rebase this?

@james7132 is this still useful for your animation plans?

[james7132]

The curves are definitely still needed. However, I think it would be better to use the Animatable trait over Lerp as it also addresses blending values a more clean way.

[lassade]

@lassade, can you rebase this?

I can't :(

[alice-i-cecile]

Fair enough. I'll close this out; we should reuse (and credit) this code later when attempting to tackle this down the road.