mirror of
https://github.com/bevyengine/bevy
synced 2025-02-16 22:18:33 +00:00
5 commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Joona Aalto
|
54006b107b
|
Migrate meshes and materials to required components (#15524)
# Objective A big step in the migration to required components: meshes and materials! ## Solution As per the [selected proposal](https://hackmd.io/@bevy/required_components/%2Fj9-PnF-2QKK0on1KQ29UWQ): - Deprecate `MaterialMesh2dBundle`, `MaterialMeshBundle`, and `PbrBundle`. - Add `Mesh2d` and `Mesh3d` components, which wrap a `Handle<Mesh>`. - Add `MeshMaterial2d<M: Material2d>` and `MeshMaterial3d<M: Material>`, which wrap a `Handle<M>`. - Meshes *without* a mesh material should be rendered with a default material. The existence of a material is determined by `HasMaterial2d`/`HasMaterial3d`, which is required by `MeshMaterial2d`/`MeshMaterial3d`. This gets around problems with the generics. Previously: ```rust commands.spawn(MaterialMesh2dBundle { mesh: meshes.add(Circle::new(100.0)).into(), material: materials.add(Color::srgb(7.5, 0.0, 7.5)), transform: Transform::from_translation(Vec3::new(-200., 0., 0.)), ..default() }); ``` Now: ```rust commands.spawn(( Mesh2d(meshes.add(Circle::new(100.0))), MeshMaterial2d(materials.add(Color::srgb(7.5, 0.0, 7.5))), Transform::from_translation(Vec3::new(-200., 0., 0.)), )); ``` If the mesh material is missing, previously nothing was rendered. Now, it renders a white default `ColorMaterial` in 2D and a `StandardMaterial` in 3D (this can be overridden). Below, only every other entity has a material:   Why white? This is still open for discussion, but I think white makes sense for a *default* material, while *invalid* asset handles pointing to nothing should have something like a pink material to indicate that something is broken (I don't handle that in this PR yet). This is kind of a mix of Godot and Unity: Godot just renders a white material for non-existent materials, while Unity renders nothing when no materials exist, but renders pink for invalid materials. I can also change the default material to pink if that is preferable though. ## Testing I ran some 2D and 3D examples to test if anything changed visually. I have not tested all examples or features yet however. If anyone wants to test more extensively, it would be appreciated! ## Implementation Notes - The relationship between `bevy_render` and `bevy_pbr` is weird here. `bevy_render` needs `Mesh3d` for its own systems, but `bevy_pbr` has all of the material logic, and `bevy_render` doesn't depend on it. I feel like the two crates should be refactored in some way, but I think that's out of scope for this PR. - I didn't migrate meshlets to required components yet. That can probably be done in a follow-up, as this is already a huge PR. - It is becoming increasingly clear to me that we really, *really* want to disallow raw asset handles as components. They caused me a *ton* of headache here already, and it took me a long time to find every place that queried for them or inserted them directly on entities, since there were no compiler errors for it. If we don't remove the `Component` derive, I expect raw asset handles to be a *huge* footgun for users as we transition to wrapper components, especially as handles as components have been the norm so far. I personally consider this to be a blocker for 0.15: we need to migrate to wrapper components for asset handles everywhere, and remove the `Component` derive. Also see https://github.com/bevyengine/bevy/issues/14124. --- ## Migration Guide Asset handles for meshes and mesh materials must now be wrapped in the `Mesh2d` and `MeshMaterial2d` or `Mesh3d` and `MeshMaterial3d` components for 2D and 3D respectively. Raw handles as components no longer render meshes. Additionally, `MaterialMesh2dBundle`, `MaterialMeshBundle`, and `PbrBundle` have been deprecated. Instead, use the mesh and material components directly. Previously: ```rust commands.spawn(MaterialMesh2dBundle { mesh: meshes.add(Circle::new(100.0)).into(), material: materials.add(Color::srgb(7.5, 0.0, 7.5)), transform: Transform::from_translation(Vec3::new(-200., 0., 0.)), ..default() }); ``` Now: ```rust commands.spawn(( Mesh2d(meshes.add(Circle::new(100.0))), MeshMaterial2d(materials.add(Color::srgb(7.5, 0.0, 7.5))), Transform::from_translation(Vec3::new(-200., 0., 0.)), )); ``` If the mesh material is missing, a white default material is now used. Previously, nothing was rendered if the material was missing. The `WithMesh2d` and `WithMesh3d` query filter type aliases have also been removed. Simply use `With<Mesh2d>` or `With<Mesh3d>`. --------- Co-authored-by: Tim Blackbird <justthecooldude@gmail.com> Co-authored-by: Carter Anderson <mcanders1@gmail.com> |
||
Zachary Harrold
|
d70595b667
|
Add core and alloc over std Lints (#15281)
# Objective - Fixes #6370 - Closes #6581 ## Solution - Added the following lints to the workspace: - `std_instead_of_core` - `std_instead_of_alloc` - `alloc_instead_of_core` - Used `cargo +nightly fmt` with [item level use formatting](https://rust-lang.github.io/rustfmt/?version=v1.6.0&search=#Item%5C%3A) to split all `use` statements into single items. - Used `cargo clippy --workspace --all-targets --all-features --fix --allow-dirty` to _attempt_ to resolve the new linting issues, and intervened where the lint was unable to resolve the issue automatically (usually due to needing an `extern crate alloc;` statement in a crate root). - Manually removed certain uses of `std` where negative feature gating prevented `--all-features` from finding the offending uses. - Used `cargo +nightly fmt` with [crate level use formatting](https://rust-lang.github.io/rustfmt/?version=v1.6.0&search=#Crate%5C%3A) to re-merge all `use` statements matching Bevy's previous styling. - Manually fixed cases where the `fmt` tool could not re-merge `use` statements due to conditional compilation attributes. ## Testing - Ran CI locally ## Migration Guide The MSRV is now 1.81. Please update to this version or higher. ## Notes - This is a _massive_ change to try and push through, which is why I've outlined the semi-automatic steps I used to create this PR, in case this fails and someone else tries again in the future. - Making this change has no impact on user code, but does mean Bevy contributors will be warned to use `core` and `alloc` instead of `std` where possible. - This lint is a critical first step towards investigating `no_std` options for Bevy. --------- Co-authored-by: François Mockers <francois.mockers@vleue.com> |
||
Robert Walter
|
8895113784
|
Use Isometry in bevy_gizmos wherever we can (#14676)
# Objective - Solves the last bullet in and closes #14319 - Make better use of the `Isometry` types - Prevent issues like #14655 - Probably simplify and clean up a lot of code through the use of Gizmos as well (i.e. the 3D gizmos for cylinders circles & lines don't connect well, probably due to wrong rotations) ## Solution - go through the `bevy_gizmos` crate and give all methods a slight workover ## Testing - For all the changed examples I run `git switch main && cargo rr --example <X> && git switch <BRANCH> && cargo rr --example <X>` and compare the visual results - Check if all doc tests are still compiling - Check the docs in general and update them !!! --- ## Migration Guide The gizmos methods function signature changes as follows: - 2D - if it took `position` & `rotation_angle` before -> `Isometry2d::new(position, Rot2::radians(rotation_angle))` - if it just took `position` before -> `Isometry2d::from_translation(position)` - 3D - if it took `position` & `rotation` before -> `Isometry3d::new(position, rotation)` - if it just took `position` before -> `Isometry3d::from_translation(position)` |
||
Matty
|
601cf6b9e5
|
Refactor Bounded2d/Bounded3d to use isometries (#14485)
# Objective Previously, this area of bevy_math used raw translation and rotations to encode isometries, which did not exist earlier. The goal of this PR is to make the codebase of bevy_math more harmonious by using actual isometries (`Isometry2d`/`Isometry3d`) in these places instead — this will hopefully make the interfaces more digestible for end-users, in addition to facilitating conversions. For instance, together with the addition of #14478, this means that a bounding box for a collider with an isometric `Transform` can be computed as ```rust collider.aabb_3d(collider_transform.to_isometry()) ``` instead of using manual destructuring. ## Solution - The traits `Bounded2d` and `Bounded3d` now use `Isometry2d` and `Isometry3d` (respectively) instead of `translation` and `rotation` parameters; e.g.: ```rust /// A trait with methods that return 3D bounding volumes for a shape. pub trait Bounded3d { /// Get an axis-aligned bounding box for the shape translated and rotated by the given isometry. fn aabb_3d(&self, isometry: Isometry3d) -> Aabb3d; /// Get a bounding sphere for the shape translated and rotated by the given isometry. fn bounding_sphere(&self, isometry: Isometry3d) -> BoundingSphere; } ``` - Similarly, the `from_point_cloud` constructors for axis-aligned bounding boxes and bounding circles/spheres now take isometries instead of separate `translation` and `rotation`; e.g.: ```rust /// Computes the smallest [`Aabb3d`] containing the given set of points, /// transformed by the rotation and translation of the given isometry. /// /// # Panics /// /// Panics if the given set of points is empty. #[inline(always)] pub fn from_point_cloud( isometry: Isometry3d, points: impl Iterator<Item = impl Into<Vec3A>>, ) -> Aabb3d { //... } ``` This has a couple additional results: 1. The end-user no longer interacts directly with `Into<Vec3A>` or `Into<Rot2>` parameters; these conversions all happen earlier now, inside the isometry types. 2. Similarly, almost all intermediate `Vec3 -> Vec3A` conversions have been eliminated from the `Bounded3d` implementations for primitives. This probably has some performance benefit, but I have not measured it as of now. ## Testing Existing unit tests help ensure that nothing has been broken in the refactor. --- ## Migration Guide The `Bounded2d` and `Bounded3d` traits now take `Isometry2d` and `Isometry3d` parameters (respectively) instead of separate translation and rotation arguments. Existing calls to `aabb_2d`, `bounding_circle`, `aabb_3d`, and `bounding_sphere` will have to be changed to use isometries instead. A straightforward conversion is to refactor just by calling `Isometry2d/3d::new`, as follows: ```rust // Old: let aabb = my_shape.aabb_2d(my_translation, my_rotation); // New: let aabb = my_shape.aabb_2d(Isometry2d::new(my_translation, my_rotation)); ``` However, if the old translation and rotation are 3d translation/rotations originating from a `Transform` or `GlobalTransform`, then `to_isometry` may be used instead. For example: ```rust // Old: let bounding_sphere = my_shape.bounding_sphere(shape_transform.translation, shape_transform.rotation); // New: let bounding_sphere = my_shape.bounding_sphere(shape_transform.to_isometry()); ``` This discussion also applies to the `from_point_cloud` construction method of `Aabb2d`/`BoundingCircle`/`Aabb3d`/`BoundingSphere`, which has similarly been altered to use isometries. |
||
Ben Harper
|
ec01c2dc45
|
New circular primitives: Arc2d, CircularSector, CircularSegment (#13482)
# Objective Adopted #11748 ## Solution I've rebased on main to fix the merge conflicts. ~~Not quite ready to merge yet~~ * Clippy is happy and the tests are passing, but... * ~~The new shapes in `examples/2d/2d_shapes.rs` don't look right at all~~ Never mind, looks like radians and degrees just got mixed up at some point? * I have updated one doc comment based on a review in the original PR. --------- Co-authored-by: Alexis "spectria" Horizon <spectria.limina@gmail.com> Co-authored-by: Alexis "spectria" Horizon <118812919+spectria-limina@users.noreply.github.com> Co-authored-by: Joona Aalto <jondolf.dev@gmail.com> Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com> Co-authored-by: Ben Harper <ben@tukom.org> |