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

35 lines
1.2 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"
Release 0.13.0 (#11920) Bump Bevy crates to 0.13.0 in preparation for release. (Note that we accidentally skipped the `0.13.0-dev` step this cycle)
2024-02-17 09:24:25 +00:00
version = "0.13.0"
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"] }
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 }
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
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
Reference in a new issue Copy permalink