Mirrors/bevy
2
0
Fork 0
mirror of https://github.com/bevyengine/bevy synced 2024-12-23 11:33:06 +00:00
Code Issues Projects Releases Packages Wiki Activity
bevy/crates/bevy_math/Cargo.toml

40 lines
1.3 KiB
TOML
Raw Normal View History

Comprehensive CONTRIBUTING.md (#2040) [**RENDERED**](https://github.com/alice-i-cecile/bevy/blob/better-contributing/CONTRIBUTING.md) Improves #910. As discussed in #1309, we'll need to synchronize content between this and the Bevy website in some way (and clean up the .github file perhaps?). I think doing it as a root-directory file is nicer for discovery, but that's a conversation I'm interested in having. This document is intended to be helpful to beginners to open source and Bevy, and captures what I've learned about our informal practices and values. Reviewers: I'm particularly interested in: - opinions on the items **What we're trying to build**, where I discuss some of the project's high-level values and goals - more relevant details on the `bevy` subcrates for **Getting oriented** - useful tricks and best practices that I missed - better guidance on how to contribute to the Bevy book from @cart <3
2021-08-14 19:21:36 +00:00
[package]
name = "bevy_math"
Bump Version after Release (#12020) Fixes #12016. Bump version after release This PR has been auto-generated Co-authored-by: Bevy Auto Releaser <41898282+github-actions[bot]@users.noreply.github.com> Co-authored-by: François <mockersf@gmail.com>
2024-02-21 20:58:59 +00:00
version = "0.14.0-dev"
Update to edition 2021 on master (#3028) Objective During work on #3009 I've found that not all jobs use actions-rs, and therefore, an previous version of Rust is used for them. So while compilation and other stuff can pass, checking markup and Android build may fail with compilation errors. Solution This PR adds `action-rs` for any job running cargo, and updates the edition to 2021.
2021-10-27 00:12:14 +00:00
edition = "2021"
Comprehensive CONTRIBUTING.md (#2040) [**RENDERED**](https://github.com/alice-i-cecile/bevy/blob/better-contributing/CONTRIBUTING.md) Improves #910. As discussed in #1309, we'll need to synchronize content between this and the Bevy website in some way (and clean up the .github file perhaps?). I think doing it as a root-directory file is nicer for discovery, but that's a conversation I'm interested in having. This document is intended to be helpful to beginners to open source and Bevy, and captures what I've learned about our informal practices and values. Reviewers: I'm particularly interested in: - opinions on the items **What we're trying to build**, where I discuss some of the project's high-level values and goals - more relevant details on the `bevy` subcrates for **Getting oriented** - useful tricks and best practices that I missed - better guidance on how to contribute to the Bevy book from @cart <3
2021-08-14 19:21:36 +00:00
description = "Provides math functionality for Bevy Engine"
homepage = "https://bevyengine.org"
repository = "https://github.com/bevyengine/bevy"
license = "MIT OR Apache-2.0"
keywords = ["bevy"]
[dependencies]
Update `glam`, `encase` and `hexasphere` (#11082) Update to `glam` 0.25, `encase` 0.7 and `hexasphere` to 10.0 ## Changelog Added the `FloatExt` trait to the `bevy_math` prelude which adds `lerp`, `inverse_lerp` and `remap` methods to the `f32` and `f64` types.
2024-01-08 22:58:45 +00:00
glam = { version = "0.25", features = ["bytemuck"] }
Cubic splines overhaul (#10701) # Objective Improve the `bevy::math::cubic_splines` module by making it more flexible and adding new curve types. Closes #10220 ## Solution Added new spline types and improved existing --- ## Changelog ### Added - `CubicNurbs` rational cubic curve generator, allows setting the knot vector and weights associated with every point - `LinearSpline` curve generator, allows generating a linearly interpolated curve segment - Ability to push additional cubic segments to `CubicCurve` - `IntoIterator` and `Extend` implementations for `CubicCurve` ### Changed - `Point` trait has been implemented for more types: `Quat` and `Vec4`. - `CubicCurve::coefficients` was moved to `CubicSegment::coefficients` because the function returns `CubicSegment`, so it seems logical to be associated with `CubicSegment` instead. The method is still not public. ### Fixed - `CubicBSpline::new` was referencing Cardinal spline instead of B-Spline --------- Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com> Co-authored-by: IQuick 143 <IQuick143cz@gmail.com> Co-authored-by: Miles Silberling-Cook <nth.tensor@gmail.com> Co-authored-by: Joona Aalto <jondolf.dev@gmail.com>
2024-02-28 17:18:42 +00:00
thiserror = "1.0"
add serialize feature to bevy_transform (#6379) # Objective Fixes #6378 `bevy_transform` is missing a feature corresponding to the `serialize` feature on the `bevy` crate. ## Solution Adds a `serialize` feature to `bevy_transform`. Derives `serde::Serialize` and `Deserialize` when feature is enabled.
2022-10-31 16:12:15 +00:00
serde = { version = "1", features = ["derive"], optional = true }
Add `Rotation2d` (#11658) # Objective Rotating vectors is a very common task. It is required for a variety of things both within Bevy itself and in many third party plugins, for example all over physics and collision detection, and for things like Bevy's bounding volumes and several gizmo implementations. For 3D, we can do this using a `Quat`, but for 2D, we do not have a clear and efficient option. `Mat2` can be used for rotating vectors if created using `Mat2::from_angle`, but this is not obvious to many users, it doesn't have many rotation helpers, and the type does not give any guarantees that it represents a valid rotation. We should have a proper type for 2D rotations. In addition to allowing for potential optimization, it would allow us to have a consistent and explicitly documented representation used throughout the engine, i.e. counterclockwise and in radians. ## Representation The mathematical formula for rotating a 2D vector is the following: ``` new_x = x * cos - y * sin new_y = x * sin + y * cos ``` Here, `sin` and `cos` are the sine and cosine of the rotation angle. Computing these every time when a vector needs to be rotated can be expensive, so the rotation shouldn't be just an `f32` angle. Instead, it is often more efficient to represent the rotation using the sine and cosine of the angle instead of storing the angle itself. This can be freely passed around and reused without unnecessary computations. The two options are either a 2x2 rotation matrix or a unit complex number where the cosine is the real part and the sine is the imaginary part. These are equivalent for the most part, but the unit complex representation is a bit more memory efficient (two `f32`s instead of four), so I chose that. This is like Nalgebra's [`UnitComplex`](https://docs.rs/nalgebra/latest/nalgebra/geometry/type.UnitComplex.html) type, which can be used for the [`Rotation2`](https://docs.rs/nalgebra/latest/nalgebra/geometry/type.Rotation2.html) type. ## Implementation Add a `Rotation2d` type represented as a unit complex number: ```rust /// A counterclockwise 2D rotation in radians. /// /// The rotation angle is wrapped to be within the `]-pi, pi]` range. pub struct Rotation2d { /// The cosine of the rotation angle in radians. /// /// This is the real part of the unit complex number representing the rotation. pub cos: f32, /// The sine of the rotation angle in radians. /// /// This is the imaginary part of the unit complex number representing the rotation. pub sin: f32, } ``` Using it is similar to using `Quat`, but in 2D: ```rust let rotation = Rotation2d::radians(PI / 2.0); // Rotate vector (also works on Direction2d!) assert_eq!(rotation * Vec2::X, Vec2::Y); // Get angle as degrees assert_eq!(rotation.as_degrees(), 90.0); // Getting sin and cos is free let (sin, cos) = rotation.sin_cos(); // "Subtract" rotations let rotation2 = Rotation2d::FRAC_PI_4; // there are constants! let diff = rotation * rotation2.inverse(); assert_eq!(diff.as_radians(), PI / 4.0); // This is equivalent to the above assert_eq!(rotation2.angle_between(rotation), PI / 4.0); // Lerp let rotation1 = Rotation2d::IDENTITY; let rotation2 = Rotation2d::FRAC_PI_2; let result = rotation1.lerp(rotation2, 0.5); assert_eq!(result.as_radians(), std::f32::consts::FRAC_PI_4); // Slerp let rotation1 = Rotation2d::FRAC_PI_4); let rotation2 = Rotation2d::degrees(-180.0); // we can use degrees too! let result = rotation1.slerp(rotation2, 1.0 / 3.0); assert_eq!(result.as_radians(), std::f32::consts::FRAC_PI_2); ``` There's also a `From<f32>` implementation for `Rotation2d`, which means that methods can still accept radians as floats if the argument uses `impl Into<Rotation2d>`. This means that adding `Rotation2d` shouldn't even be a breaking change. --- ## Changelog - Added `Rotation2d` - Bounding volume methods now take an `impl Into<Rotation2d>` - Gizmo methods with rotation now take an `impl Into<Rotation2d>` ## Future use cases - Collision detection (a type like this is quite essential considering how common vector rotations are) - `Transform` helpers (e.g. return a 2D rotation about the Z axis from a `Transform`) - The rotation used for `Transform2d` (#8268) - More gizmos, maybe meshes... everything in 2D that uses rotation --------- Co-authored-by: Tristan Guichaoua <33934311+tguichaoua@users.noreply.github.com> Co-authored-by: Robert Walter <robwalter96@gmail.com> Co-authored-by: IQuick 143 <IQuick143cz@gmail.com>
2024-03-11 19:11:57 +00:00
libm = { version = "0.2", optional = true }
Implement `approx` traits for direction types (#11650) # Objective `approx` has traits like [`AbsDiffEq`](https://docs.rs/approx/latest/approx/trait.AbsDiffEq.html), [`RelativeEq`](https://docs.rs/approx/latest/approx/trait.RelativeEq.html), and [`UlpsEq`](https://docs.rs/approx/latest/approx/trait.UlpsEq.html). Glam implements them for its math types when the `approx` feature is enabled. Bevy's `Direction2d` and `Direction3d` should implement these too. ## Solution Implement the traits. See [how Glam implements them for its own math types](https://github.com/bitshifter/glam-rs/blob/main/src/features/impl_approx.rs). For the epsilon values, I use the same as `Vec2`/`Vec3` (just `f32::EPSILON`).
2024-02-01 19:22:28 +00:00
approx = { version = "0.5", optional = true }
Expose mint feature in bevy_math/glam (#5857) # Objective - Expose `mint` feature of `glam` in `bevy_math`. - Unblocks harudagondi/bevy_oddio#22 - [`oddio::SpatialOptions`] uses mint types [`oddio::SpatialOptions`]: https://docs.rs/oddio/latest/oddio/struct.SpatialOptions.html ## Solution - Added features in `bevy_math`, ~`bevy_internal`, `bevy`~ - ~Updated `docs/cargo_features.md`~ --- ## Changelog ### Added - `mint` feature in `bevy_math` to allow interoperation of glam types with mint-compatible libraries.
2022-09-03 03:02:04 +00:00
Add more constructors and math helpers for primitive shapes (#10632) # Objective Working towards finishing a part of #10572, this PR adds a ton of math helpers and useful constructors for primitive shapes. I also tried fixing some naming inconsistencies. ## Solution - Add mathematical helpers like `area`, `volume`, `perimeter`, `RegularPolygon::inradius` and so on, trying to cover all core mathematical properties of each shape - Add some constructors like `Rectangle::from_corners`, `Cuboid::from_corners` and `Plane3d::from_points` I also derived `PartialEq` for the shapes where it's trivial. Primitives like `Line2d` and `Segment2d` are not trivial because you could argue that they would be equal if they had an opposite direction. All mathematical methods have tests with reference values computed by hand or with external tools. ## Todo - [x] Add tests to verify that the values from mathematical helpers are correct --------- Co-authored-by: IQuick 143 <IQuick143cz@gmail.com>
2024-01-29 16:04:51 +00:00
[dev-dependencies]
approx = "0.5"
Expose mint feature in bevy_math/glam (#5857) # Objective - Expose `mint` feature of `glam` in `bevy_math`. - Unblocks harudagondi/bevy_oddio#22 - [`oddio::SpatialOptions`] uses mint types [`oddio::SpatialOptions`]: https://docs.rs/oddio/latest/oddio/struct.SpatialOptions.html ## Solution - Added features in `bevy_math`, ~`bevy_internal`, `bevy`~ - ~Updated `docs/cargo_features.md`~ --- ## Changelog ### Added - `mint` feature in `bevy_math` to allow interoperation of glam types with mint-compatible libraries.
2022-09-03 03:02:04 +00:00
[features]
Re-export glam_assert feature (#8232) # Objective - Allow the use of the "glam _assert" feature to help catch runtime errors and validate the arguments passed to glam. e.g. ```rs // Will panic if self is zero length when glam_assert is enabled. pub fn normalize(self) -> Self { let normalized = self.mul(self.length_recip()); glam_assert!(normalized.is_finite()); normalized } ``` ## Solution - Re-export the optional feature glam_assert --- ## Changelog Added: Optional feature "glam_assert"
2023-03-28 20:18:50 +00:00
serialize = ["dep:serde", "glam/serde"]
Add `approx` feature to `bevy_math` (#11176) # Objective `bevy_math` re-exports Glam, but doesn't have a feature for enabling `approx` for it. Many projects (including some of Bevy's own crates) need `approx`, and it'd be nice if you didn't have to manually add Glam to specify the feature for it. ## Solution Add an `approx` feature to `bevy_math`.
2024-01-02 18:10:44 +00:00
# Enable approx for glam types to approximate floating point equality comparisons and assertions
Implement `approx` traits for direction types (#11650) # Objective `approx` has traits like [`AbsDiffEq`](https://docs.rs/approx/latest/approx/trait.AbsDiffEq.html), [`RelativeEq`](https://docs.rs/approx/latest/approx/trait.RelativeEq.html), and [`UlpsEq`](https://docs.rs/approx/latest/approx/trait.UlpsEq.html). Glam implements them for its math types when the `approx` feature is enabled. Bevy's `Direction2d` and `Direction3d` should implement these too. ## Solution Implement the traits. See [how Glam implements them for its own math types](https://github.com/bitshifter/glam-rs/blob/main/src/features/impl_approx.rs). For the epsilon values, I use the same as `Vec2`/`Vec3` (just `f32::EPSILON`).
2024-02-01 19:22:28 +00:00
approx = ["dep:approx", "glam/approx"]
Expose mint feature in bevy_math/glam (#5857) # Objective - Expose `mint` feature of `glam` in `bevy_math`. - Unblocks harudagondi/bevy_oddio#22 - [`oddio::SpatialOptions`] uses mint types [`oddio::SpatialOptions`]: https://docs.rs/oddio/latest/oddio/struct.SpatialOptions.html ## Solution - Added features in `bevy_math`, ~`bevy_internal`, `bevy`~ - ~Updated `docs/cargo_features.md`~ --- ## Changelog ### Added - `mint` feature in `bevy_math` to allow interoperation of glam types with mint-compatible libraries.
2022-09-03 03:02:04 +00:00
# Enable interoperation of glam types with mint-compatible libraries
mint = ["glam/mint"]
Add `libm` feature to `bevy_math` (#11238) # Objective Different platforms use their own implementations of several mathematical functions (especially transcendental functions like sin, cos, tan, atan, and so on) to provide hardware-level optimization using intrinsics. This is good for performance, but bad when you expect consistent outputs across machines. [`libm`](https://github.com/rust-lang/libm) is a widely used crate that provides mathematical functions that don't use intrinsics like `std` functions. This allows bit-for-bit deterministic math across hardware, which is crucial for things like cross-platform deterministic physics simulation. Glam has the `libm` feature for using [`libm` for the math](https://github.com/bitshifter/glam-rs/blob/d2871a151bb1ecc91bb160e1c1cce336d8a52d9d/src/f32/math.rs#L35) in its own types. This would be nice to expose as a feature in `bevy_math`. ## Solution Add `libm` feature to `bevy_math`. We could name it something like `enhanced-determinism`, but this wouldn't be accurate for the rest of Bevy, so I think just `libm` is more fitting and explicit.
2024-01-06 22:01:57 +00:00
# Enable libm mathematical functions for glam types to ensure consistent outputs
# across platforms at the cost of losing hardware-level optimization using intrinsics
Add `Rotation2d` (#11658) # Objective Rotating vectors is a very common task. It is required for a variety of things both within Bevy itself and in many third party plugins, for example all over physics and collision detection, and for things like Bevy's bounding volumes and several gizmo implementations. For 3D, we can do this using a `Quat`, but for 2D, we do not have a clear and efficient option. `Mat2` can be used for rotating vectors if created using `Mat2::from_angle`, but this is not obvious to many users, it doesn't have many rotation helpers, and the type does not give any guarantees that it represents a valid rotation. We should have a proper type for 2D rotations. In addition to allowing for potential optimization, it would allow us to have a consistent and explicitly documented representation used throughout the engine, i.e. counterclockwise and in radians. ## Representation The mathematical formula for rotating a 2D vector is the following: ``` new_x = x * cos - y * sin new_y = x * sin + y * cos ``` Here, `sin` and `cos` are the sine and cosine of the rotation angle. Computing these every time when a vector needs to be rotated can be expensive, so the rotation shouldn't be just an `f32` angle. Instead, it is often more efficient to represent the rotation using the sine and cosine of the angle instead of storing the angle itself. This can be freely passed around and reused without unnecessary computations. The two options are either a 2x2 rotation matrix or a unit complex number where the cosine is the real part and the sine is the imaginary part. These are equivalent for the most part, but the unit complex representation is a bit more memory efficient (two `f32`s instead of four), so I chose that. This is like Nalgebra's [`UnitComplex`](https://docs.rs/nalgebra/latest/nalgebra/geometry/type.UnitComplex.html) type, which can be used for the [`Rotation2`](https://docs.rs/nalgebra/latest/nalgebra/geometry/type.Rotation2.html) type. ## Implementation Add a `Rotation2d` type represented as a unit complex number: ```rust /// A counterclockwise 2D rotation in radians. /// /// The rotation angle is wrapped to be within the `]-pi, pi]` range. pub struct Rotation2d { /// The cosine of the rotation angle in radians. /// /// This is the real part of the unit complex number representing the rotation. pub cos: f32, /// The sine of the rotation angle in radians. /// /// This is the imaginary part of the unit complex number representing the rotation. pub sin: f32, } ``` Using it is similar to using `Quat`, but in 2D: ```rust let rotation = Rotation2d::radians(PI / 2.0); // Rotate vector (also works on Direction2d!) assert_eq!(rotation * Vec2::X, Vec2::Y); // Get angle as degrees assert_eq!(rotation.as_degrees(), 90.0); // Getting sin and cos is free let (sin, cos) = rotation.sin_cos(); // "Subtract" rotations let rotation2 = Rotation2d::FRAC_PI_4; // there are constants! let diff = rotation * rotation2.inverse(); assert_eq!(diff.as_radians(), PI / 4.0); // This is equivalent to the above assert_eq!(rotation2.angle_between(rotation), PI / 4.0); // Lerp let rotation1 = Rotation2d::IDENTITY; let rotation2 = Rotation2d::FRAC_PI_2; let result = rotation1.lerp(rotation2, 0.5); assert_eq!(result.as_radians(), std::f32::consts::FRAC_PI_4); // Slerp let rotation1 = Rotation2d::FRAC_PI_4); let rotation2 = Rotation2d::degrees(-180.0); // we can use degrees too! let result = rotation1.slerp(rotation2, 1.0 / 3.0); assert_eq!(result.as_radians(), std::f32::consts::FRAC_PI_2); ``` There's also a `From<f32>` implementation for `Rotation2d`, which means that methods can still accept radians as floats if the argument uses `impl Into<Rotation2d>`. This means that adding `Rotation2d` shouldn't even be a breaking change. --- ## Changelog - Added `Rotation2d` - Bounding volume methods now take an `impl Into<Rotation2d>` - Gizmo methods with rotation now take an `impl Into<Rotation2d>` ## Future use cases - Collision detection (a type like this is quite essential considering how common vector rotations are) - `Transform` helpers (e.g. return a 2D rotation about the Z axis from a `Transform`) - The rotation used for `Transform2d` (#8268) - More gizmos, maybe meshes... everything in 2D that uses rotation --------- Co-authored-by: Tristan Guichaoua <33934311+tguichaoua@users.noreply.github.com> Co-authored-by: Robert Walter <robwalter96@gmail.com> Co-authored-by: IQuick 143 <IQuick143cz@gmail.com>
2024-03-11 19:11:57 +00:00
libm = ["dep:libm", "glam/libm"]
Re-export glam_assert feature (#8232) # Objective - Allow the use of the "glam _assert" feature to help catch runtime errors and validate the arguments passed to glam. e.g. ```rs // Will panic if self is zero length when glam_assert is enabled. pub fn normalize(self) -> Self { let normalized = self.mul(self.length_recip()); glam_assert!(normalized.is_finite()); normalized } ``` ## Solution - Re-export the optional feature glam_assert --- ## Changelog Added: Optional feature "glam_assert"
2023-03-28 20:18:50 +00:00
# Enable assertions to check the validity of parameters passed to glam
glam_assert = ["glam/glam-assert"]
re-export `debug_glam_assert` feature (#10206) # Objective - I want to use the `debug_glam_assert` feature with bevy. ## Solution - Re-export the feature flag --- ## Changelog - Re-export `debug_glam_assert` feature flag from glam.
2023-10-22 23:01:28 +00:00
# Enable assertions in debug builds to check the validity of parameters passed to glam
debug_glam_assert = ["glam/debug-glam-assert"]
Add [lints] table, fix adding `#![allow(clippy::type_complexity)]` everywhere (#10011) # Objective - Fix adding `#![allow(clippy::type_complexity)]` everywhere. like #9796 ## Solution - Use the new [lints] table that will land in 1.74 (https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#lints) - inherit lint to the workspace, crates and examples. ``` [lints] workspace = true ``` ## Changelog - Bump rust version to 1.74 - Enable lints table for the workspace ```toml [workspace.lints.clippy] type_complexity = "allow" ``` - Allow type complexity for all crates and examples ```toml [lints] workspace = true ``` --------- Co-authored-by: Martín Maita <47983254+mnmaita@users.noreply.github.com>
2023-11-18 20:58:48 +00:00
[lints]
workspace = true
Add "all-features = true" to docs.rs metadata for most crates (#12366) # Objective Fix missing `TextBundle` (and many others) which are present in the main crate as default features but optional in the sub-crate. See: - https://docs.rs/bevy/0.13.0/bevy/ui/node_bundles/index.html - https://docs.rs/bevy_ui/0.13.0/bevy_ui/node_bundles/index.html ~~There are probably other instances in other crates that I could track down, but maybe "all-features = true" should be used by default in all sub-crates? Not sure.~~ (There were many.) I only noticed this because rust-analyzer's "open docs" features takes me to the sub-crate, not the main one. ## Solution Add "all-features = true" to docs.rs metadata for crates that use features. ## Changelog ### Changed - Unified features documented on docs.rs between main crate and sub-crates
2024-03-08 20:03:09 +00:00
[package.metadata.docs.rs]
all-features = true
Reference in a new issue Copy permalink