2024-07-09 17:16:47 +00:00
|
|
|
//! This module contains abstract mathematical traits shared by types used in `bevy_math`.
|
|
|
|
|
Make bevy_math's `libm` feature use `libm` for all `f32`methods with unspecified precision (#14693)
# Objective
Closes #14474
Previously, the `libm` feature of bevy_math would just pass the same
feature flag down to glam. However, bevy_math itself had many uses of
floating-point arithmetic with unspecified precision. For example,
`f32::sin_cos` and `f32::powi` have unspecified precision, which means
that the exact details of their output are not guaranteed to be stable
across different systems and/or versions of Rust. This means that users
of bevy_math could observe slightly different behavior on different
systems if these methods were used.
The goal of this PR is to make it so that the `libm` feature flag
actually guarantees some degree of determinacy within bevy_math itself
by switching to the libm versions of these functions when the `libm`
feature is enabled.
## Solution
bevy_math now has an internal module `bevy_math::ops`, which re-exports
either the standard versions of the operations or the libm versions
depending on whether the `libm` feature is enabled. For example,
`ops::sin` compiles to `f32::sin` without the `libm` feature and to
`libm::sinf` with it.
This approach has a small shortfall, which is that `f32::powi` (integer
powers of floating point numbers) does not have an equivalent in `libm`.
On the other hand, this method is only used for squaring and cubing
numbers in bevy_math. Accordingly, this deficit is covered by the
introduction of a trait `ops::FloatPow`:
```rust
pub(crate) trait FloatPow {
fn squared(self) -> Self;
fn cubed(self) -> Self;
}
```
Next, each current usage of the unspecified-precision methods has been
replaced by its equivalent in `ops`, so that when `libm` is enabled, the
libm version is used instead. The exception, of course, is that
`.powi(2)`/`.powi(3)` have been replaced with `.squared()`/`.cubed()`.
Finally, the usage of the plain `f32` methods with unspecified precision
is now linted out of bevy_math (and hence disallowed in CI). For
example, using `f32::sin` within bevy_math produces a warning that tells
the user to use the `ops::sin` version instead.
## Testing
Ran existing tests. It would be nice to check some benchmarks on NURBS
things once #14677 merges. I'm happy to wait until then if the rest of
this PR is fine.
---
## Discussion
In the future, it might make sense to actually expose `bevy_math::ops`
as public if any downstream Bevy crates want to provide similar
determinacy guarantees. For now, it's all just `pub(crate)`.
This PR also only covers `f32`. If we find ourselves using `f64`
internally in parts of bevy_math for better robustness, we could extend
the module and lints to cover the `f64` versions easily enough.
I don't know how feasible it is, but it would also be nice if we could
standardize the bevy_math tests with the `libm` feature in CI, since
their success is currently platform-dependent (e.g. 8 of them fail on my
machine when run locally).
---------
Co-authored-by: IQuick 143 <IQuick143cz@gmail.com>
2024-08-12 16:13:36 +00:00
|
|
|
use crate::{ops, Dir2, Dir3, Dir3A, Quat, Rot2, Vec2, Vec3, Vec3A, Vec4};
|
2024-09-27 00:59:59 +00:00
|
|
|
use core::{
|
2024-09-24 11:42:59 +00:00
|
|
|
fmt::Debug,
|
|
|
|
ops::{Add, Div, Mul, Neg, Sub},
|
|
|
|
};
|
Move `Point` out of cubic splines module and expand it (#12747)
# Objective
Previously, the `Point` trait, which abstracts all of the operations of
a real vector space, was sitting in the submodule of `bevy_math` for
cubic splines. However, the trait has broader applications than merely
cubic splines, and we should use it when possible to avoid code
duplication when performing vector operations.
## Solution
`Point` has been moved into a new submodule in `bevy_math` named
`common_traits`. Furthermore, it has been renamed to `VectorSpace`,
which is more descriptive, and an additional trait `NormedVectorSpace`
has been introduced to expand the API to cover situations involving
geometry in addition to algebra. Additionally, `VectorSpace` itself now
requires a `ZERO` constant and `Neg`. It also supports a `lerp` function
as an automatic trait method.
Here is what that looks like:
```rust
/// A type that supports the mathematical operations of a real vector space, irrespective of dimension.
/// In particular, this means that the implementing type supports:
/// - Scalar multiplication and division on the right by elements of `f32`
/// - Negation
/// - Addition and subtraction
/// - Zero
///
/// Within the limitations of floating point arithmetic, all the following are required to hold:
/// - (Associativity of addition) For all `u, v, w: Self`, `(u + v) + w == u + (v + w)`.
/// - (Commutativity of addition) For all `u, v: Self`, `u + v == v + u`.
/// - (Additive identity) For all `v: Self`, `v + Self::ZERO == v`.
/// - (Additive inverse) For all `v: Self`, `v - v == v + (-v) == Self::ZERO`.
/// - (Compatibility of multiplication) For all `a, b: f32`, `v: Self`, `v * (a * b) == (v * a) * b`.
/// - (Multiplicative identity) For all `v: Self`, `v * 1.0 == v`.
/// - (Distributivity for vector addition) For all `a: f32`, `u, v: Self`, `(u + v) * a == u * a + v * a`.
/// - (Distributivity for scalar addition) For all `a, b: f32`, `v: Self`, `v * (a + b) == v * a + v * b`.
///
/// Note that, because implementing types use floating point arithmetic, they are not required to actually
/// implement `PartialEq` or `Eq`.
pub trait VectorSpace:
Mul<f32, Output = Self>
+ Div<f32, Output = Self>
+ Add<Self, Output = Self>
+ Sub<Self, Output = Self>
+ Neg
+ Default
+ Debug
+ Clone
+ Copy
{
/// The zero vector, which is the identity of addition for the vector space type.
const ZERO: Self;
/// Perform vector space linear interpolation between this element and another, based
/// on the parameter `t`. When `t` is `0`, `self` is recovered. When `t` is `1`, `rhs`
/// is recovered.
///
/// Note that the value of `t` is not clamped by this function, so interpolating outside
/// of the interval `[0,1]` is allowed.
#[inline]
fn lerp(&self, rhs: Self, t: f32) -> Self {
*self * (1. - t) + rhs * t
}
}
```
```rust
/// A type that supports the operations of a normed vector space; i.e. a norm operation in addition
/// to those of [`VectorSpace`]. Specifically, the implementor must guarantee that the following
/// relationships hold, within the limitations of floating point arithmetic:
/// - (Nonnegativity) For all `v: Self`, `v.norm() >= 0.0`.
/// - (Positive definiteness) For all `v: Self`, `v.norm() == 0.0` implies `v == Self::ZERO`.
/// - (Absolute homogeneity) For all `c: f32`, `v: Self`, `(v * c).norm() == v.norm() * c.abs()`.
/// - (Triangle inequality) For all `v, w: Self`, `(v + w).norm() <= v.norm() + w.norm()`.
///
/// Note that, because implementing types use floating point arithmetic, they are not required to actually
/// implement `PartialEq` or `Eq`.
pub trait NormedVectorSpace: VectorSpace {
/// The size of this element. The return value should always be nonnegative.
fn norm(self) -> f32;
/// The squared norm of this element. Computing this is often faster than computing
/// [`NormedVectorSpace::norm`].
#[inline]
fn norm_squared(self) -> f32 {
self.norm() * self.norm()
}
/// The distance between this element and another, as determined by the norm.
#[inline]
fn distance(self, rhs: Self) -> f32 {
(rhs - self).norm()
}
/// The squared distance between this element and another, as determined by the norm. Note that
/// this is often faster to compute in practice than [`NormedVectorSpace::distance`].
#[inline]
fn distance_squared(self, rhs: Self) -> f32 {
(rhs - self).norm_squared()
}
}
```
Furthermore, this PR also demonstrates the use of the
`NormedVectorSpace` combined API to implement `ShapeSample` for
`Triangle2d` and `Triangle3d` simultaneously. Such deduplication is one
of the drivers for developing these APIs.
---
## Changelog
- `Point` from `cubic_splines` becomes `VectorSpace`, exported as
`bevy::math::VectorSpace`.
- `VectorSpace` requires `Neg` and `VectorSpace::ZERO` in addition to
its existing prerequisites.
- Introduced public traits `bevy::math::NormedVectorSpace` for generic
geometry tasks involving vectors.
- Implemented `ShapeSample` for `Triangle2d` and `Triangle3d`.
## Migration Guide
Since `Point` no longer exists, any projects using it must switch to
`bevy::math::VectorSpace`. Additionally, third-party implementations of
this trait now require the `Neg` trait; the constant `VectorSpace::ZERO`
must be provided as well.
---
## Discussion
### Design considerations
Originally, the `NormedVectorSpace::norm` method was part of a separate
trait `Normed`. However, I think that was probably too broad and, more
importantly, the semantics of having it in `NormedVectorSpace` are much
clearer.
As it currently stands, the API exposed here is pretty minimal, and
there is definitely a lot more that we could do, but there are more
questions to answer along the way. As a silly example, we could
implement `NormedVectorSpace::length` as an alias for
`NormedVectorSpace::norm`, but this overlaps with methods in all of the
glam types, so we would want to make sure that the implementations are
effectively identical (for what it's worth, I think they are already).
### Future directions
One example of something that could belong in the `NormedVectorSpace`
API is normalization. Actually, such a thing previously existed on this
branch before I decided to shelve it because of concerns with namespace
collision. It looked like this:
```rust
/// This element, but normalized to norm 1 if possible. Returns an error when the reciprocal of
/// the element's norm is not finite.
#[inline]
#[must_use]
fn normalize(&self) -> Result<Self, NonNormalizableError> {
let reciprocal = 1.0 / self.norm();
if reciprocal.is_finite() {
Ok(*self * reciprocal)
} else {
Err(NonNormalizableError { reciprocal })
}
}
/// An error indicating that an element of a [`NormedVectorSpace`] was non-normalizable due to having
/// non-finite norm-reciprocal.
#[derive(Debug, Error)]
#[error("Element with norm reciprocal {reciprocal} cannot be normalized")]
pub struct NonNormalizableError {
reciprocal: f32
}
```
With this kind of thing in hand, it might be worth considering
eventually making the passage from vectors to directions fully generic
by employing a wrapper type. (Of course, for our concrete types, we
would leave the existing names in place as aliases.) That is, something
like:
```rust
pub struct NormOne<T>
where T: NormedVectorSpace { //... }
```
Utterly separately, the reason that I implemented `ShapeSample` for
`Triangle2d`/`Triangle3d` was to prototype uniform sampling of abstract
meshes, so that's also a future direction.
---------
Co-authored-by: Zachary Harrold <zac@harrold.com.au>
2024-03-28 13:40:26 +00:00
|
|
|
|
|
|
|
/// A type that supports the mathematical operations of a real vector space, irrespective of dimension.
|
|
|
|
/// In particular, this means that the implementing type supports:
|
|
|
|
/// - Scalar multiplication and division on the right by elements of `f32`
|
|
|
|
/// - Negation
|
|
|
|
/// - Addition and subtraction
|
|
|
|
/// - Zero
|
|
|
|
///
|
|
|
|
/// Within the limitations of floating point arithmetic, all the following are required to hold:
|
|
|
|
/// - (Associativity of addition) For all `u, v, w: Self`, `(u + v) + w == u + (v + w)`.
|
|
|
|
/// - (Commutativity of addition) For all `u, v: Self`, `u + v == v + u`.
|
|
|
|
/// - (Additive identity) For all `v: Self`, `v + Self::ZERO == v`.
|
|
|
|
/// - (Additive inverse) For all `v: Self`, `v - v == v + (-v) == Self::ZERO`.
|
|
|
|
/// - (Compatibility of multiplication) For all `a, b: f32`, `v: Self`, `v * (a * b) == (v * a) * b`.
|
|
|
|
/// - (Multiplicative identity) For all `v: Self`, `v * 1.0 == v`.
|
|
|
|
/// - (Distributivity for vector addition) For all `a: f32`, `u, v: Self`, `(u + v) * a == u * a + v * a`.
|
|
|
|
/// - (Distributivity for scalar addition) For all `a, b: f32`, `v: Self`, `v * (a + b) == v * a + v * b`.
|
|
|
|
///
|
|
|
|
/// Note that, because implementing types use floating point arithmetic, they are not required to actually
|
|
|
|
/// implement `PartialEq` or `Eq`.
|
|
|
|
pub trait VectorSpace:
|
|
|
|
Mul<f32, Output = Self>
|
|
|
|
+ Div<f32, Output = Self>
|
|
|
|
+ Add<Self, Output = Self>
|
|
|
|
+ Sub<Self, Output = Self>
|
|
|
|
+ Neg
|
|
|
|
+ Default
|
|
|
|
+ Debug
|
|
|
|
+ Clone
|
|
|
|
+ Copy
|
|
|
|
{
|
|
|
|
/// The zero vector, which is the identity of addition for the vector space type.
|
|
|
|
const ZERO: Self;
|
|
|
|
|
|
|
|
/// Perform vector space linear interpolation between this element and another, based
|
|
|
|
/// on the parameter `t`. When `t` is `0`, `self` is recovered. When `t` is `1`, `rhs`
|
|
|
|
/// is recovered.
|
|
|
|
///
|
|
|
|
/// Note that the value of `t` is not clamped by this function, so interpolating outside
|
|
|
|
/// of the interval `[0,1]` is allowed.
|
|
|
|
#[inline]
|
|
|
|
fn lerp(&self, rhs: Self, t: f32) -> Self {
|
|
|
|
*self * (1. - t) + rhs * t
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl VectorSpace for Vec4 {
|
|
|
|
const ZERO: Self = Vec4::ZERO;
|
|
|
|
}
|
|
|
|
|
|
|
|
impl VectorSpace for Vec3 {
|
|
|
|
const ZERO: Self = Vec3::ZERO;
|
|
|
|
}
|
|
|
|
|
|
|
|
impl VectorSpace for Vec3A {
|
|
|
|
const ZERO: Self = Vec3A::ZERO;
|
|
|
|
}
|
|
|
|
|
|
|
|
impl VectorSpace for Vec2 {
|
|
|
|
const ZERO: Self = Vec2::ZERO;
|
|
|
|
}
|
|
|
|
|
|
|
|
impl VectorSpace for f32 {
|
|
|
|
const ZERO: Self = 0.0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/// A type that supports the operations of a normed vector space; i.e. a norm operation in addition
|
|
|
|
/// to those of [`VectorSpace`]. Specifically, the implementor must guarantee that the following
|
|
|
|
/// relationships hold, within the limitations of floating point arithmetic:
|
|
|
|
/// - (Nonnegativity) For all `v: Self`, `v.norm() >= 0.0`.
|
|
|
|
/// - (Positive definiteness) For all `v: Self`, `v.norm() == 0.0` implies `v == Self::ZERO`.
|
|
|
|
/// - (Absolute homogeneity) For all `c: f32`, `v: Self`, `(v * c).norm() == v.norm() * c.abs()`.
|
|
|
|
/// - (Triangle inequality) For all `v, w: Self`, `(v + w).norm() <= v.norm() + w.norm()`.
|
|
|
|
///
|
|
|
|
/// Note that, because implementing types use floating point arithmetic, they are not required to actually
|
|
|
|
/// implement `PartialEq` or `Eq`.
|
|
|
|
pub trait NormedVectorSpace: VectorSpace {
|
|
|
|
/// The size of this element. The return value should always be nonnegative.
|
|
|
|
fn norm(self) -> f32;
|
|
|
|
|
|
|
|
/// The squared norm of this element. Computing this is often faster than computing
|
|
|
|
/// [`NormedVectorSpace::norm`].
|
|
|
|
#[inline]
|
|
|
|
fn norm_squared(self) -> f32 {
|
|
|
|
self.norm() * self.norm()
|
|
|
|
}
|
|
|
|
|
|
|
|
/// The distance between this element and another, as determined by the norm.
|
|
|
|
#[inline]
|
|
|
|
fn distance(self, rhs: Self) -> f32 {
|
|
|
|
(rhs - self).norm()
|
|
|
|
}
|
|
|
|
|
|
|
|
/// The squared distance between this element and another, as determined by the norm. Note that
|
|
|
|
/// this is often faster to compute in practice than [`NormedVectorSpace::distance`].
|
|
|
|
#[inline]
|
|
|
|
fn distance_squared(self, rhs: Self) -> f32 {
|
|
|
|
(rhs - self).norm_squared()
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl NormedVectorSpace for Vec4 {
|
|
|
|
#[inline]
|
|
|
|
fn norm(self) -> f32 {
|
|
|
|
self.length()
|
|
|
|
}
|
|
|
|
|
|
|
|
#[inline]
|
|
|
|
fn norm_squared(self) -> f32 {
|
|
|
|
self.length_squared()
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl NormedVectorSpace for Vec3 {
|
|
|
|
#[inline]
|
|
|
|
fn norm(self) -> f32 {
|
|
|
|
self.length()
|
|
|
|
}
|
|
|
|
|
|
|
|
#[inline]
|
|
|
|
fn norm_squared(self) -> f32 {
|
|
|
|
self.length_squared()
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl NormedVectorSpace for Vec3A {
|
|
|
|
#[inline]
|
|
|
|
fn norm(self) -> f32 {
|
|
|
|
self.length()
|
|
|
|
}
|
|
|
|
|
|
|
|
#[inline]
|
|
|
|
fn norm_squared(self) -> f32 {
|
|
|
|
self.length_squared()
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl NormedVectorSpace for Vec2 {
|
|
|
|
#[inline]
|
|
|
|
fn norm(self) -> f32 {
|
|
|
|
self.length()
|
|
|
|
}
|
|
|
|
|
|
|
|
#[inline]
|
|
|
|
fn norm_squared(self) -> f32 {
|
|
|
|
self.length_squared()
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl NormedVectorSpace for f32 {
|
|
|
|
#[inline]
|
|
|
|
fn norm(self) -> f32 {
|
|
|
|
self.abs()
|
|
|
|
}
|
|
|
|
|
|
|
|
#[inline]
|
|
|
|
fn norm_squared(self) -> f32 {
|
|
|
|
self * self
|
|
|
|
}
|
|
|
|
}
|
Stable interpolation and smooth following (#13741)
# Objective
Partially address #13408
Rework of #13613
Unify the very nice forms of interpolation specifically present in
`bevy_math` under a shared trait upon which further behavior can be
based.
The ideas in this PR were prompted by [Lerp smoothing is broken by Freya
Holmer](https://www.youtube.com/watch?v=LSNQuFEDOyQ).
## Solution
There is a new trait `StableInterpolate` in `bevy_math::common_traits`
which enshrines a quite-specific notion of interpolation with a lot of
guarantees:
```rust
/// A type with a natural interpolation that provides strong subdivision guarantees.
///
/// Although the only required method is `interpolate_stable`, many things are expected of it:
///
/// 1. The notion of interpolation should follow naturally from the semantics of the type, so
/// that inferring the interpolation mode from the type alone is sensible.
///
/// 2. The interpolation recovers something equivalent to the starting value at `t = 0.0`
/// and likewise with the ending value at `t = 1.0`.
///
/// 3. Importantly, the interpolation must be *subdivision-stable*: for any interpolation curve
/// between two (unnamed) values and any parameter-value pairs `(t0, p)` and `(t1, q)`, the
/// interpolation curve between `p` and `q` must be the *linear* reparametrization of the original
/// interpolation curve restricted to the interval `[t0, t1]`.
///
/// The last of these conditions is very strong and indicates something like constant speed. It
/// is called "subdivision stability" because it guarantees that breaking up the interpolation
/// into segments and joining them back together has no effect.
///
/// Here is a diagram depicting it:
/// ```text
/// top curve = u.interpolate_stable(v, t)
///
/// t0 => p t1 => q
/// |-------------|---------|-------------|
/// 0 => u / \ 1 => v
/// / \
/// / \
/// / linear \
/// / reparametrization \
/// / t = t0 * (1 - s) + t1 * s \
/// / \
/// |-------------------------------------|
/// 0 => p 1 => q
///
/// bottom curve = p.interpolate_stable(q, s)
/// ```
///
/// Note that some common forms of interpolation do not satisfy this criterion. For example,
/// [`Quat::lerp`] and [`Rot2::nlerp`] are not subdivision-stable.
///
/// Furthermore, this is not to be used as a general trait for abstract interpolation.
/// Consumers rely on the strong guarantees in order for behavior based on this trait to be
/// well-behaved.
///
/// [`Quat::lerp`]: crate::Quat::lerp
/// [`Rot2::nlerp`]: crate::Rot2::nlerp
pub trait StableInterpolate: Clone {
/// Interpolate between this value and the `other` given value using the parameter `t`.
/// Note that the parameter `t` is not necessarily clamped to lie between `0` and `1`.
/// When `t = 0.0`, `self` is recovered, while `other` is recovered at `t = 1.0`,
/// with intermediate values lying between the two.
fn interpolate_stable(&self, other: &Self, t: f32) -> Self;
}
```
This trait has a blanket implementation over `NormedVectorSpace`, where
`lerp` is used, along with implementations for `Rot2`, `Quat`, and the
direction types using variants of `slerp`. Other areas may choose to
implement this trait in order to hook into its functionality, but the
stringent requirements must actually be met.
This trait bears no direct relationship with `bevy_animation`'s
`Animatable` trait, although they may choose to use `interpolate_stable`
in their trait implementations if they wish, as both traits involve
type-inferred interpolations of the same kind. `StableInterpolate` is
not a supertrait of `Animatable` for a couple reasons:
1. Notions of interpolation in animation are generally going to be much
more general than those allowed under these constraints.
2. Laying out these generalized interpolation notions is the domain of
`bevy_animation` rather than of `bevy_math`. (Consider also that
inferring interpolation from types is not universally desirable.)
Similarly, this is not implemented on `bevy_color`'s color types,
although their current mixing behavior does meet the conditions of the
trait.
As an aside, the subdivision-stability condition is of interest
specifically for the [Curve
RFC](https://github.com/bevyengine/rfcs/pull/80), where it also ensures
a kind of stability for subsampling.
Importantly, this trait ensures that the "smooth following" behavior
defined in this PR behaves predictably:
```rust
/// Smoothly nudge this value towards the `target` at a given decay rate. The `decay_rate`
/// parameter controls how fast the distance between `self` and `target` decays relative to
/// the units of `delta`; the intended usage is for `decay_rate` to generally remain fixed,
/// while `delta` is something like `delta_time` from an updating system. This produces a
/// smooth following of the target that is independent of framerate.
///
/// More specifically, when this is called repeatedly, the result is that the distance between
/// `self` and a fixed `target` attenuates exponentially, with the rate of this exponential
/// decay given by `decay_rate`.
///
/// For example, at `decay_rate = 0.0`, this has no effect.
/// At `decay_rate = f32::INFINITY`, `self` immediately snaps to `target`.
/// In general, higher rates mean that `self` moves more quickly towards `target`.
///
/// # Example
/// ```
/// # use bevy_math::{Vec3, StableInterpolate};
/// # let delta_time: f32 = 1.0 / 60.0;
/// let mut object_position: Vec3 = Vec3::ZERO;
/// let target_position: Vec3 = Vec3::new(2.0, 3.0, 5.0);
/// // Decay rate of ln(10) => after 1 second, remaining distance is 1/10th
/// let decay_rate = f32::ln(10.0);
/// // Calling this repeatedly will move `object_position` towards `target_position`:
/// object_position.smooth_nudge(&target_position, decay_rate, delta_time);
/// ```
fn smooth_nudge(&mut self, target: &Self, decay_rate: f32, delta: f32) {
self.interpolate_stable_assign(target, 1.0 - f32::exp(-decay_rate * delta));
}
```
As the documentation indicates, the intention is for this to be called
in game update systems, and `delta` would be something like
`Time::delta_seconds` in Bevy, allowing positions, orientations, and so
on to smoothly follow a target. A new example, `smooth_follow`,
demonstrates a basic implementation of this, with a sphere smoothly
following a sharply moving target:
https://github.com/bevyengine/bevy/assets/2975848/7124b28b-6361-47e3-acf7-d1578ebd0347
## Testing
Tested by running the example with various parameters.
2024-06-10 12:50:59 +00:00
|
|
|
|
|
|
|
/// A type with a natural interpolation that provides strong subdivision guarantees.
|
|
|
|
///
|
|
|
|
/// Although the only required method is `interpolate_stable`, many things are expected of it:
|
|
|
|
///
|
|
|
|
/// 1. The notion of interpolation should follow naturally from the semantics of the type, so
|
|
|
|
/// that inferring the interpolation mode from the type alone is sensible.
|
|
|
|
///
|
|
|
|
/// 2. The interpolation recovers something equivalent to the starting value at `t = 0.0`
|
|
|
|
/// and likewise with the ending value at `t = 1.0`. They do not have to be data-identical, but
|
|
|
|
/// they should be semantically identical. For example, [`Quat::slerp`] doesn't always yield its
|
|
|
|
/// second rotation input exactly at `t = 1.0`, but it always returns an equivalent rotation.
|
|
|
|
///
|
|
|
|
/// 3. Importantly, the interpolation must be *subdivision-stable*: for any interpolation curve
|
|
|
|
/// between two (unnamed) values and any parameter-value pairs `(t0, p)` and `(t1, q)`, the
|
|
|
|
/// interpolation curve between `p` and `q` must be the *linear* reparametrization of the original
|
|
|
|
/// interpolation curve restricted to the interval `[t0, t1]`.
|
|
|
|
///
|
|
|
|
/// The last of these conditions is very strong and indicates something like constant speed. It
|
|
|
|
/// is called "subdivision stability" because it guarantees that breaking up the interpolation
|
|
|
|
/// into segments and joining them back together has no effect.
|
|
|
|
///
|
|
|
|
/// Here is a diagram depicting it:
|
|
|
|
/// ```text
|
|
|
|
/// top curve = u.interpolate_stable(v, t)
|
|
|
|
///
|
|
|
|
/// t0 => p t1 => q
|
|
|
|
/// |-------------|---------|-------------|
|
|
|
|
/// 0 => u / \ 1 => v
|
|
|
|
/// / \
|
|
|
|
/// / \
|
|
|
|
/// / linear \
|
|
|
|
/// / reparametrization \
|
|
|
|
/// / t = t0 * (1 - s) + t1 * s \
|
|
|
|
/// / \
|
|
|
|
/// |-------------------------------------|
|
|
|
|
/// 0 => p 1 => q
|
|
|
|
///
|
|
|
|
/// bottom curve = p.interpolate_stable(q, s)
|
|
|
|
/// ```
|
|
|
|
///
|
|
|
|
/// Note that some common forms of interpolation do not satisfy this criterion. For example,
|
|
|
|
/// [`Quat::lerp`] and [`Rot2::nlerp`] are not subdivision-stable.
|
|
|
|
///
|
|
|
|
/// Furthermore, this is not to be used as a general trait for abstract interpolation.
|
|
|
|
/// Consumers rely on the strong guarantees in order for behavior based on this trait to be
|
|
|
|
/// well-behaved.
|
|
|
|
///
|
|
|
|
/// [`Quat::slerp`]: crate::Quat::slerp
|
|
|
|
/// [`Quat::lerp`]: crate::Quat::lerp
|
|
|
|
/// [`Rot2::nlerp`]: crate::Rot2::nlerp
|
|
|
|
pub trait StableInterpolate: Clone {
|
|
|
|
/// Interpolate between this value and the `other` given value using the parameter `t`. At
|
|
|
|
/// `t = 0.0`, a value equivalent to `self` is recovered, while `t = 1.0` recovers a value
|
|
|
|
/// equivalent to `other`, with intermediate values interpolating between the two.
|
|
|
|
/// See the [trait-level documentation] for details.
|
|
|
|
///
|
|
|
|
/// [trait-level documentation]: StableInterpolate
|
|
|
|
fn interpolate_stable(&self, other: &Self, t: f32) -> Self;
|
|
|
|
|
|
|
|
/// A version of [`interpolate_stable`] that assigns the result to `self` for convenience.
|
|
|
|
///
|
|
|
|
/// [`interpolate_stable`]: StableInterpolate::interpolate_stable
|
|
|
|
fn interpolate_stable_assign(&mut self, other: &Self, t: f32) {
|
|
|
|
*self = self.interpolate_stable(other, t);
|
|
|
|
}
|
|
|
|
|
|
|
|
/// Smoothly nudge this value towards the `target` at a given decay rate. The `decay_rate`
|
|
|
|
/// parameter controls how fast the distance between `self` and `target` decays relative to
|
|
|
|
/// the units of `delta`; the intended usage is for `decay_rate` to generally remain fixed,
|
|
|
|
/// while `delta` is something like `delta_time` from an updating system. This produces a
|
|
|
|
/// smooth following of the target that is independent of framerate.
|
|
|
|
///
|
|
|
|
/// More specifically, when this is called repeatedly, the result is that the distance between
|
|
|
|
/// `self` and a fixed `target` attenuates exponentially, with the rate of this exponential
|
|
|
|
/// decay given by `decay_rate`.
|
|
|
|
///
|
|
|
|
/// For example, at `decay_rate = 0.0`, this has no effect.
|
|
|
|
/// At `decay_rate = f32::INFINITY`, `self` immediately snaps to `target`.
|
|
|
|
/// In general, higher rates mean that `self` moves more quickly towards `target`.
|
|
|
|
///
|
|
|
|
/// # Example
|
|
|
|
/// ```
|
|
|
|
/// # use bevy_math::{Vec3, StableInterpolate};
|
|
|
|
/// # let delta_time: f32 = 1.0 / 60.0;
|
|
|
|
/// let mut object_position: Vec3 = Vec3::ZERO;
|
|
|
|
/// let target_position: Vec3 = Vec3::new(2.0, 3.0, 5.0);
|
|
|
|
/// // Decay rate of ln(10) => after 1 second, remaining distance is 1/10th
|
|
|
|
/// let decay_rate = f32::ln(10.0);
|
|
|
|
/// // Calling this repeatedly will move `object_position` towards `target_position`:
|
|
|
|
/// object_position.smooth_nudge(&target_position, decay_rate, delta_time);
|
|
|
|
/// ```
|
|
|
|
fn smooth_nudge(&mut self, target: &Self, decay_rate: f32, delta: f32) {
|
Make bevy_math's `libm` feature use `libm` for all `f32`methods with unspecified precision (#14693)
# Objective
Closes #14474
Previously, the `libm` feature of bevy_math would just pass the same
feature flag down to glam. However, bevy_math itself had many uses of
floating-point arithmetic with unspecified precision. For example,
`f32::sin_cos` and `f32::powi` have unspecified precision, which means
that the exact details of their output are not guaranteed to be stable
across different systems and/or versions of Rust. This means that users
of bevy_math could observe slightly different behavior on different
systems if these methods were used.
The goal of this PR is to make it so that the `libm` feature flag
actually guarantees some degree of determinacy within bevy_math itself
by switching to the libm versions of these functions when the `libm`
feature is enabled.
## Solution
bevy_math now has an internal module `bevy_math::ops`, which re-exports
either the standard versions of the operations or the libm versions
depending on whether the `libm` feature is enabled. For example,
`ops::sin` compiles to `f32::sin` without the `libm` feature and to
`libm::sinf` with it.
This approach has a small shortfall, which is that `f32::powi` (integer
powers of floating point numbers) does not have an equivalent in `libm`.
On the other hand, this method is only used for squaring and cubing
numbers in bevy_math. Accordingly, this deficit is covered by the
introduction of a trait `ops::FloatPow`:
```rust
pub(crate) trait FloatPow {
fn squared(self) -> Self;
fn cubed(self) -> Self;
}
```
Next, each current usage of the unspecified-precision methods has been
replaced by its equivalent in `ops`, so that when `libm` is enabled, the
libm version is used instead. The exception, of course, is that
`.powi(2)`/`.powi(3)` have been replaced with `.squared()`/`.cubed()`.
Finally, the usage of the plain `f32` methods with unspecified precision
is now linted out of bevy_math (and hence disallowed in CI). For
example, using `f32::sin` within bevy_math produces a warning that tells
the user to use the `ops::sin` version instead.
## Testing
Ran existing tests. It would be nice to check some benchmarks on NURBS
things once #14677 merges. I'm happy to wait until then if the rest of
this PR is fine.
---
## Discussion
In the future, it might make sense to actually expose `bevy_math::ops`
as public if any downstream Bevy crates want to provide similar
determinacy guarantees. For now, it's all just `pub(crate)`.
This PR also only covers `f32`. If we find ourselves using `f64`
internally in parts of bevy_math for better robustness, we could extend
the module and lints to cover the `f64` versions easily enough.
I don't know how feasible it is, but it would also be nice if we could
standardize the bevy_math tests with the `libm` feature in CI, since
their success is currently platform-dependent (e.g. 8 of them fail on my
machine when run locally).
---------
Co-authored-by: IQuick 143 <IQuick143cz@gmail.com>
2024-08-12 16:13:36 +00:00
|
|
|
self.interpolate_stable_assign(target, 1.0 - ops::exp(-decay_rate * delta));
|
Stable interpolation and smooth following (#13741)
# Objective
Partially address #13408
Rework of #13613
Unify the very nice forms of interpolation specifically present in
`bevy_math` under a shared trait upon which further behavior can be
based.
The ideas in this PR were prompted by [Lerp smoothing is broken by Freya
Holmer](https://www.youtube.com/watch?v=LSNQuFEDOyQ).
## Solution
There is a new trait `StableInterpolate` in `bevy_math::common_traits`
which enshrines a quite-specific notion of interpolation with a lot of
guarantees:
```rust
/// A type with a natural interpolation that provides strong subdivision guarantees.
///
/// Although the only required method is `interpolate_stable`, many things are expected of it:
///
/// 1. The notion of interpolation should follow naturally from the semantics of the type, so
/// that inferring the interpolation mode from the type alone is sensible.
///
/// 2. The interpolation recovers something equivalent to the starting value at `t = 0.0`
/// and likewise with the ending value at `t = 1.0`.
///
/// 3. Importantly, the interpolation must be *subdivision-stable*: for any interpolation curve
/// between two (unnamed) values and any parameter-value pairs `(t0, p)` and `(t1, q)`, the
/// interpolation curve between `p` and `q` must be the *linear* reparametrization of the original
/// interpolation curve restricted to the interval `[t0, t1]`.
///
/// The last of these conditions is very strong and indicates something like constant speed. It
/// is called "subdivision stability" because it guarantees that breaking up the interpolation
/// into segments and joining them back together has no effect.
///
/// Here is a diagram depicting it:
/// ```text
/// top curve = u.interpolate_stable(v, t)
///
/// t0 => p t1 => q
/// |-------------|---------|-------------|
/// 0 => u / \ 1 => v
/// / \
/// / \
/// / linear \
/// / reparametrization \
/// / t = t0 * (1 - s) + t1 * s \
/// / \
/// |-------------------------------------|
/// 0 => p 1 => q
///
/// bottom curve = p.interpolate_stable(q, s)
/// ```
///
/// Note that some common forms of interpolation do not satisfy this criterion. For example,
/// [`Quat::lerp`] and [`Rot2::nlerp`] are not subdivision-stable.
///
/// Furthermore, this is not to be used as a general trait for abstract interpolation.
/// Consumers rely on the strong guarantees in order for behavior based on this trait to be
/// well-behaved.
///
/// [`Quat::lerp`]: crate::Quat::lerp
/// [`Rot2::nlerp`]: crate::Rot2::nlerp
pub trait StableInterpolate: Clone {
/// Interpolate between this value and the `other` given value using the parameter `t`.
/// Note that the parameter `t` is not necessarily clamped to lie between `0` and `1`.
/// When `t = 0.0`, `self` is recovered, while `other` is recovered at `t = 1.0`,
/// with intermediate values lying between the two.
fn interpolate_stable(&self, other: &Self, t: f32) -> Self;
}
```
This trait has a blanket implementation over `NormedVectorSpace`, where
`lerp` is used, along with implementations for `Rot2`, `Quat`, and the
direction types using variants of `slerp`. Other areas may choose to
implement this trait in order to hook into its functionality, but the
stringent requirements must actually be met.
This trait bears no direct relationship with `bevy_animation`'s
`Animatable` trait, although they may choose to use `interpolate_stable`
in their trait implementations if they wish, as both traits involve
type-inferred interpolations of the same kind. `StableInterpolate` is
not a supertrait of `Animatable` for a couple reasons:
1. Notions of interpolation in animation are generally going to be much
more general than those allowed under these constraints.
2. Laying out these generalized interpolation notions is the domain of
`bevy_animation` rather than of `bevy_math`. (Consider also that
inferring interpolation from types is not universally desirable.)
Similarly, this is not implemented on `bevy_color`'s color types,
although their current mixing behavior does meet the conditions of the
trait.
As an aside, the subdivision-stability condition is of interest
specifically for the [Curve
RFC](https://github.com/bevyengine/rfcs/pull/80), where it also ensures
a kind of stability for subsampling.
Importantly, this trait ensures that the "smooth following" behavior
defined in this PR behaves predictably:
```rust
/// Smoothly nudge this value towards the `target` at a given decay rate. The `decay_rate`
/// parameter controls how fast the distance between `self` and `target` decays relative to
/// the units of `delta`; the intended usage is for `decay_rate` to generally remain fixed,
/// while `delta` is something like `delta_time` from an updating system. This produces a
/// smooth following of the target that is independent of framerate.
///
/// More specifically, when this is called repeatedly, the result is that the distance between
/// `self` and a fixed `target` attenuates exponentially, with the rate of this exponential
/// decay given by `decay_rate`.
///
/// For example, at `decay_rate = 0.0`, this has no effect.
/// At `decay_rate = f32::INFINITY`, `self` immediately snaps to `target`.
/// In general, higher rates mean that `self` moves more quickly towards `target`.
///
/// # Example
/// ```
/// # use bevy_math::{Vec3, StableInterpolate};
/// # let delta_time: f32 = 1.0 / 60.0;
/// let mut object_position: Vec3 = Vec3::ZERO;
/// let target_position: Vec3 = Vec3::new(2.0, 3.0, 5.0);
/// // Decay rate of ln(10) => after 1 second, remaining distance is 1/10th
/// let decay_rate = f32::ln(10.0);
/// // Calling this repeatedly will move `object_position` towards `target_position`:
/// object_position.smooth_nudge(&target_position, decay_rate, delta_time);
/// ```
fn smooth_nudge(&mut self, target: &Self, decay_rate: f32, delta: f32) {
self.interpolate_stable_assign(target, 1.0 - f32::exp(-decay_rate * delta));
}
```
As the documentation indicates, the intention is for this to be called
in game update systems, and `delta` would be something like
`Time::delta_seconds` in Bevy, allowing positions, orientations, and so
on to smoothly follow a target. A new example, `smooth_follow`,
demonstrates a basic implementation of this, with a sphere smoothly
following a sharply moving target:
https://github.com/bevyengine/bevy/assets/2975848/7124b28b-6361-47e3-acf7-d1578ebd0347
## Testing
Tested by running the example with various parameters.
2024-06-10 12:50:59 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
// Conservatively, we presently only apply this for normed vector spaces, where the notion
|
|
|
|
// of being constant-speed is literally true. The technical axioms are satisfied for any
|
|
|
|
// VectorSpace type, but the "natural from the semantics" part is less clear in general.
|
|
|
|
impl<V> StableInterpolate for V
|
|
|
|
where
|
|
|
|
V: NormedVectorSpace,
|
|
|
|
{
|
|
|
|
#[inline]
|
|
|
|
fn interpolate_stable(&self, other: &Self, t: f32) -> Self {
|
|
|
|
self.lerp(*other, t)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl StableInterpolate for Rot2 {
|
|
|
|
#[inline]
|
|
|
|
fn interpolate_stable(&self, other: &Self, t: f32) -> Self {
|
|
|
|
self.slerp(*other, t)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl StableInterpolate for Quat {
|
|
|
|
#[inline]
|
|
|
|
fn interpolate_stable(&self, other: &Self, t: f32) -> Self {
|
|
|
|
self.slerp(*other, t)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl StableInterpolate for Dir2 {
|
|
|
|
#[inline]
|
|
|
|
fn interpolate_stable(&self, other: &Self, t: f32) -> Self {
|
|
|
|
self.slerp(*other, t)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl StableInterpolate for Dir3 {
|
|
|
|
#[inline]
|
|
|
|
fn interpolate_stable(&self, other: &Self, t: f32) -> Self {
|
|
|
|
self.slerp(*other, t)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
impl StableInterpolate for Dir3A {
|
|
|
|
#[inline]
|
|
|
|
fn interpolate_stable(&self, other: &Self, t: f32) -> Self {
|
|
|
|
self.slerp(*other, t)
|
|
|
|
}
|
|
|
|
}
|