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_transform/Cargo.toml

35 lines
1,005 B
TOML
Raw Normal View History

asset loading, hierarchies, more refactoring
2019-12-02 09:31:07 +00:00
[package]
EntityArchetype proc macro
2020-01-19 10:02:12 +00:00
name = "bevy_transform"
Release 0.12 (#10362) Preparing next 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>
2023-11-04 17:24:23 +00:00
version = "0.12.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"
Split bevy_hierarchy out from bevy_transform (#4168) # Objective - Hierarchy tools are not just used for `Transform`: they are also used for scenes. - In the future there's interest in using them for other features, such as visiibility inheritance. - The fact that these tools are found in `bevy_transform` causes a great deal of user and developer confusion - Fixes #2758. ## Solution - Split `bevy_transform` into two! - Make everything work again. Note that this is a very tightly scoped PR: I *know* there are code quality and docs issues that existed in bevy_transform that I've just moved around. We should fix those in a seperate PR and try to merge this ASAP to reduce the bitrot involved in splitting an entire crate. ## Frustrations The API around `GlobalTransform` is a mess: we have massive code and docs duplication, no link between the two types and no clear way to extend this to other forms of inheritance. In the medium-term, I feel pretty strongly that `GlobalTransform` should be replaced by something like `Inherited<Transform>`, which lives in `bevy_hierarchy`: - avoids code duplication - makes the inheritance pattern extensible - links the types at the type-level - allows us to remove all references to inheritance from `bevy_transform`, making it more useful as a standalone crate and cleaning up its docs ## Additional context - double-blessed by @cart in https://github.com/bevyengine/bevy/issues/4141#issuecomment-1063592414 and https://github.com/bevyengine/bevy/issues/2758#issuecomment-913810963 - preparation for more advanced / cleaner hierarchy tools: go read https://github.com/bevyengine/rfcs/pull/53 ! - originally attempted by @finegeometer in #2789. It was a great idea, just needed more discussion! Co-authored-by: Carter Anderson <mcanders1@gmail.com>
2022-03-15 01:54:05 +00:00
description = "Provides transform functionality for Bevy Engine"
add crate metadata
2020-08-10 00:24:27 +00:00
homepage = "https://bevyengine.org"
repository = "https://github.com/bevyengine/bevy"
Relicense Bevy under the dual MIT or Apache-2.0 license (#2509) This relicenses Bevy under the dual MIT or Apache-2.0 license. For rationale, see #2373. * Changes the LICENSE file to describe the dual license. Moved the MIT license to docs/LICENSE-MIT. Added the Apache-2.0 license to docs/LICENSE-APACHE. I opted for this approach over dumping both license files at the root (the more common approach) for a number of reasons: * Github links to the "first" license file (LICENSE-APACHE) in its license links (you can see this in the wgpu and rust-analyzer repos). People clicking these links might erroneously think that the apache license is the only option. Rust and Amethyst both use COPYRIGHT or COPYING files to solve this problem, but this creates more file noise (if you do everything at the root) and the naming feels way less intuitive. * People have a reflex to look for a LICENSE file. By providing a single license file at the root, we make it easy for them to understand our licensing approach. * I like keeping the root clean and noise free * There is precedent for putting the apache and mit license text in sub folders (amethyst) * Removed the `Copyright (c) 2020 Carter Anderson` copyright notice from the MIT license. I don't care about this attribution, it might make license compliance more difficult in some cases, and it didn't properly attribute other contributors. We shoudn't replace it with something like "Copyright (c) 2021 Bevy Contributors" because "Bevy Contributors" is not a legal entity. Instead, we just won't include the copyright line (which has precedent ... Rust also uses this approach). * Updates crates to use the new "MIT OR Apache-2.0" license value * Removes the old legion-transform license file from bevy_transform. bevy_transform has been its own, fully custom implementation for a long time and that license no longer applies. * Added a License section to the main readme * Updated our Bevy Plugin licensing guidelines. As a follow-up we should update the website to properly describe the new license. Closes #2373
2021-07-23 21:11:51 +00:00
license = "MIT OR Apache-2.0"
add crate metadata
2020-08-10 00:24:27 +00:00
keywords = ["bevy"]
asset loading, hierarchies, more refactoring
2019-12-02 09:31:07 +00:00
[dependencies]
add "0.1" version to all bevy crate references
2020-08-10 00:39:28 +00:00
# bevy
Release 0.12 (#10362) Preparing next 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>
2023-11-04 17:24:23 +00:00
bevy_app = { path = "../bevy_app", version = "0.12.0" }
Standardize toml format with taplo (#10594) # Objective - Standardize fmt for toml files ## Solution - Add [taplo](https://taplo.tamasfe.dev/) to CI (check for fmt and diff for toml files), for context taplo is used by the most popular extension in VScode [Even Better TOML](https://marketplace.visualstudio.com/items?itemName=tamasfe.even-better-toml - Add contribution section to explain toml fmt with taplo. Now to pass CI you need to run `taplo fmt --option indent_string=" "` or if you use vscode have the `Even Better TOML` extension with 4 spaces for indent --------- Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
2023-11-21 01:04:14 +00:00
bevy_ecs = { path = "../bevy_ecs", version = "0.12.0", features = [
"bevy_reflect",
] }
Release 0.12 (#10362) Preparing next 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>
2023-11-04 17:24:23 +00:00
bevy_hierarchy = { path = "../bevy_hierarchy", version = "0.12.0" }
bevy_math = { path = "../bevy_math", version = "0.12.0" }
Standardize toml format with taplo (#10594) # Objective - Standardize fmt for toml files ## Solution - Add [taplo](https://taplo.tamasfe.dev/) to CI (check for fmt and diff for toml files), for context taplo is used by the most popular extension in VScode [Even Better TOML](https://marketplace.visualstudio.com/items?itemName=tamasfe.even-better-toml - Add contribution section to explain toml fmt with taplo. Now to pass CI you need to run `taplo fmt --option indent_string=" "` or if you use vscode have the `Even Better TOML` extension with 4 spaces for indent --------- Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
2023-11-21 01:04:14 +00:00
bevy_reflect = { path = "../bevy_reflect", version = "0.12.0", features = [
"bevy",
] }
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 }
Derive Error for more error types (#10240) # Objective Align all error-like types to implement `Error`. Fixes #10176 ## Solution - Derive `Error` on more types - Refactor instances of manual implementations that could be derived This adds thiserror as a dependency to bevy_transform, which might increase compilation time -- but I don't know of any situation where you might only use that but not any other crate that pulls in bevy_utils. The `contributors` example has a `LoadContributorsError` type, but as it's an example I have not updated it. Doing that would mean either having a `use bevy_internal::utils::thiserror::Error;` in an example file, or adding `thiserror` as a dev-dependency to the main `bevy` crate. --- ## Changelog - All `…Error` types now implement the `Error` trait
2023-10-28 22:20:37 +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
Fix malformed dev-dependencies (#7916) This was causing the "post release version bump" to fail
2023-03-06 00:47:07 +00:00
[dev-dependencies]
Release 0.12 (#10362) Preparing next 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>
2023-11-04 17:24:23 +00:00
bevy_tasks = { path = "../bevy_tasks", version = "0.12.0" }
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
bevy_math = { path = "../bevy_math", version = "0.12.0", features = ["approx"] }
Add system parameter for computing up-to-date `GlobalTransform`s (#8603) # Objective Add a way to easily compute the up-to-date `GlobalTransform` of an entity. ## Solution Add the `TransformHelper`(Name pending) system parameter with the `compute_global_transform` method that takes an `Entity` and returns a `GlobalTransform` if successful. ## Changelog - Added the `TransformHelper` system parameter for computing the up-to-date `GlobalTransform` of an entity. --------- Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com> Co-authored-by: Noah <noahshomette@gmail.com>
2023-10-18 20:07:51 +00:00
approx = "0.5.1"
Parallelized transform propagation (#4775) # Objective Fixes #4697. Hierarchical propagation of properties, currently only Transform -> GlobalTransform, can be a very expensive operation. Transform propagation is a strict dependency for anything positioned in world-space. In large worlds, this can take quite a bit of time, so limiting it to a single thread can result in poor CPU utilization as it bottlenecks the rest of the frame's systems. ## Solution - Move transforms without a parent or a child (free-floating (Global)Transform) entities into a separate parallel system. - Chunk the hierarchy based on the root entities and process it in parallel with `Query::par_for_each_mut`. - Utilize the hierarchy's specific properties introduced in #4717 to allow for safe use of `Query::get_unchecked` on multiple threads. Assuming each child is unique in the hierarchy, it is impossible to have an aliased `&mut GlobalTransform` so long as we verify that the parent for a child is the same one propagated from. --- ## Changelog Removed: `transform_propagate_system` is no longer `pub`.
2022-11-21 18:18:38 +00:00
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
[features]
serialize = ["dep:serde", "bevy_math/serialize"]
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