This repository was archived by the owner on Apr 22, 2025. It is now read-only.
No archetype component access #1
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
CodSpeed Performance ReportMerging #1 will improve performances by ×3.5Comparing Summary
Benchmarks breakdown
|
# Objective When reviewing bevyengine#18263, I noticed that `BevyManifest` internally stores a `DocumentMut`, a mutable TOML document, instead of an `ImDocument`, an immutable one. The process of creating a `DocumentMut` first involves creating a `ImDocument` and then cloning all the referenced spans of text into their own allocations (internally referred to as `despan` in `toml_edit`). As such, using a `DocumentMut` without mutation is strictly additional overhead. In addition, I noticed that the filesystem operations associated with reading a manifest and parsing it were written to be completed _while_ a write-lock was held on `MANIFESTS`. This likely doesn't translate into a performance or deadlock issue as the manifest files are generally small and can be read quickly, but it is generally considered a bad practice. ## Solution - Switched to `ImDocument<Box<str>>` instead of `DocumentMut` - Re-ordered operations in `BevyManifest::shared` to minimise time spent holding open the write-lock on `MANIFESTS` ## Testing - CI --- ## Notes I wasn't able to measure a meaningful performance difference with this PR, so this is purely a code quality change and not one for performance. --------- Co-authored-by: Carter Anderson <[email protected]>
…vyengine#18281) # Objective Probably just because of an oversight, bounding primitives like `Aabb3d` did not implement `Serialize`/`Deserialize` with the `serialize` feature enabled, so the goal of this PR is to fill the gap. ## Solution Derive it conditionally, just like we do for everything else. Also added in `PartialEq`, just because I touched the files. ## Testing Compiled with different feature combinations.
# Objective It does not resolves issue for full support for OpenRPC for `bevy_remote`, but it is a first step in that direction. Connected to the bevyengine#16744 issue. ## Solution - Adds `rpc.discover` endpoint to the bevy_remote which follows https://spec.open-rpc.org/#openrpc-document For now in methods array only the name, which is the endpoint address is populated. - Moves json_schema structs into new module inside `bevy_remote`. ## Testing Tested the commands by running the BRP sample( cargo run --example server --features="bevy_remote") and with these curl command: ```sh curl -X POST -d '{ "jsonrpc": "2.0", "id": 1, "method": "rpc.discover"}' 127.0.0.1:15702 | jq . ``` The output is: ```json { "jsonrpc": "2.0", "id": 1, "result": { "info": { "title": "Bevy Remote Protocol", "version": "0.16.0-dev" }, "methods": [ { "name": "bevy/mutate_component", "params": [] }, { "name": "bevy/insert", "params": [] }, { "name": "bevy/get", "params": [] }, { "name": "bevy/spawn", "params": [] }, { "name": "bevy/get+watch", "params": [] }, { "name": "bevy/destroy", "params": [] }, { "name": "bevy/list", "params": [] }, { "name": "bevy/mutate_resource", "params": [] }, { "name": "bevy/reparent", "params": [] }, { "name": "bevy/registry/schema", "params": [] }, { "name": "bevy/get_resource", "params": [] }, { "name": "bevy/query", "params": [] }, { "name": "bevy/remove_resource", "params": [] }, { "name": "rpc.discover", "params": [] }, { "name": "bevy/insert_resource", "params": [] }, { "name": "bevy/list_resources", "params": [] }, { "name": "bevy/remove", "params": [] }, { "name": "bevy/list+watch", "params": [] } ], "openrpc": "1.3.2", "servers": [ { "name": "Server", "url": "127.0.0.1:15702" } ] } } ``` --------- Co-authored-by: Viktor Gustavsson <[email protected]>
# Objective Contributes to bevyengine#18238 Updates the `gamepad_viewer`, example to use the `children!` macro. ## Solution Updates examples to use the Improved Spawning API merged in bevyengine#17521 ## Testing - Did you test these changes? If so, how? - Opened the examples before and after and verified the same behavior was observed. I did this on Ubuntu 24.04.2 LTS using `--features wayland`. - Are there any parts that need more testing? - Other OS's and features can't hurt, but this is such a small change it shouldn't be a problem. - How can other people (reviewers) test your changes? Is there anything specific they need to know? - Run the examples yourself with and without these changes. - If relevant, what platforms did you test these changes on, and are there any important ones you can't test? - see above --- ## Showcase n/a ## Migration Guide n/a
# Objective While poking at bevyengine#17272, I noticed a few small things to clean up. ## Solution - Improve the docs - ~~move `SystemErrorContext` out of the `handler.rs` module: it's not an error handler~~
…ro (bevyengine#18292) # Objective Contributes to bevyengine#18238 Updates the `custom_transitions` and `sub_states` examples to use the `children!` macro. ## Solution Updates examples to use the Improved Spawning API merged in bevyengine#17521 ## Testing - Did you test these changes? If so, how? - Opened the examples before and after and verified the same behavior was observed. I did this on Ubuntu 24.04.2 LTS using `--features wayland`. - Are there any parts that need more testing? - Other OS's and features can't hurt, but this is such a small change it shouldn't be a problem. - How can other people (reviewers) test your changes? Is there anything specific they need to know? - Run the examples yourself with and without these changes. - If relevant, what platforms did you test these changes on, and are there any important ones you can't test? - see above --- ## Showcase n/a ## Migration Guide n/a
# Objective Some of Bevy's examples contain boilerplate which is split out into the `helpers` folder. This allows examples to have access to common functionality without building into Bevy directly. However, these helpers are themselves quite high-quality code, and we do intend for users to read them and even use them. But, we don't list them in the examples document, and they aren't explicitly checked in CI, only transitively through examples which import them. ## Solution - Added `camera_controller` and `widgets` as library examples. ## Testing - CI --- ## Notes - Library examples are identical to any other example, just with `crate-type = ["lib"]` in the `Cargo.toml`. Since they are marked as libraries, they don't require a `main` function but do require public items to be documented. - Library examples opens the possibility of creating examples which don't need to be actual runnable applications. This may be more appropriate for certain ECS examples, and allows for adding helpers which (currently) don't have an example that needs them without them going stale. - I learned about this as a concept during research for `no_std` examples, but believe it has value for Bevy outside that specific niche. --------- Co-authored-by: mgi388 <[email protected]> Co-authored-by: Carter Weinberg <[email protected]>
# Objective - Fixes bevyengine#18223. ## Solution - Updated ui_test requirement from 0.23.0 to 0.29.1. - Updated code to use the new APIs. ## Testing - Ran CI locally. --------- Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
# Objective Contributes to bevyengine#18238 Updates the `computed_states`, example to use the `children!` macro. Note that this example requires `--features bevy_dev_tools` to run ## Solution Updates examples to use the Improved Spawning API merged in bevyengine#17521 ## Testing - Did you test these changes? If so, how? - Opened the examples before and after and verified the same behavior was observed. I did this on Ubuntu 24.04.2 LTS using `--features wayland`. - Are there any parts that need more testing? - Other OS's and features can't hurt, but this is such a small change it shouldn't be a problem. - How can other people (reviewers) test your changes? Is there anything specific they need to know? - Run the examples yourself with and without these changes. - If relevant, what platforms did you test these changes on, and are there any important ones you can't test? - see above --- ## Showcase n/a ## Migration Guide n/a
# Objective - Implement `Bounded2d` for `ConvexPolygon`
# Objective - Prevents bevyengine#18291. - Previously, attempting to direct-nested-load a subasset would return the root of the nested-loaded asset. This is most problematic when doing direct-nested-**untyped**-loads of subassets, where you may not even realize you're dealing with the entirely wrong asset (at least with typed loads, *most of the time* the root asset has a different type from the subasset, and so at least you'd get an error that the types don't match). ## Solution - We now return an error when doing these kinds of loads. Note an alternative would be to "solve" this problem, by just looking up the appropriate subasset after doing the nested load. However there's two problems: 1) we don't know which subassets of the root asset are necessary for the subasset we are looking up (so any handles in that subasset may never get registered), 2) a solution will likely hamper attempts to resolve bevyengine#18010. AFAICT, no one has complained about this issue, so it doesn't seem critical to fix this for now. ## Testing - Added a test to ensure this returns an error. I also checked that the error before this was just a mismatched type error, meaning it was trying to pass off the root asset type `CoolText` as the subasset type `SubText` (which would have worked had I not been using typed loads).
# Objective bevyengine#13432 added proper reflection-based cloning. This is a better method than cloning via `clone_value` for reasons detailed in the description of that PR. However, it may not be immediately apparent to users why one should be used over the other, and what the gotchas of `clone_value` are. ## Solution This PR marks `PartialReflect::clone_value` as deprecated, with the deprecation notice pointing users to `PartialReflect::reflect_clone`. However, it also suggests using a new method introduced in this PR: `PartialReflect::to_dynamic`. `PartialReflect::to_dynamic` is essentially a renaming of `PartialReflect::clone_value`. By naming it `to_dynamic`, we make it very obvious that what's returned is a dynamic type. The one caveat to this is that opaque types still use `reflect_clone` as they have no corresponding dynamic type. Along with changing the name, the method is now optional, and comes with a default implementation that calls out to the respective reflection subtrait method. This was done because there was really no reason to require manual implementors provide a method that almost always calls out to a known set of methods. Lastly, to make this default implementation work, this PR also did a similar thing with the `clone_dynamic ` methods on the reflection subtraits. For example, `Struct::clone_dynamic` has been marked deprecated and is superseded by `Struct::to_dynamic_struct`. This was necessary to avoid the "multiple names in scope" issue. ### Open Questions This PR maintains the original signature of `clone_value` on `to_dynamic`. That is, it takes `&self` and returns `Box<dyn PartialReflect>`. However, in order for this to work, it introduces a panic if the value is opaque and doesn't override the default `reflect_clone` implementation. One thing we could do to avoid the panic would be to make the conversion fallible, either returning `Option<Box<dyn PartialReflect>>` or `Result<Box<dyn PartialReflect>, ReflectCloneError>`. This makes using the method a little more involved (i.e. users have to either unwrap or handle the rare possibility of an error), but it would set us up for a world where opaque types don't strictly need to be `Clone`. Right now this bound is sort of implied by the fact that `clone_value` is a required trait method, and the default behavior of the macro is to use `Clone` for opaque types. Alternatively, we could keep the signature but make the method required. This maintains that implied bound where manual implementors must provide some way of cloning the value (or YOLO it and just panic), but also makes the API simpler to use. Finally, we could just leave it with the panic. It's unlikely this would occur in practice since our macro still requires `Clone` for opaque types, and thus this would only ever be an issue if someone were to manually implement `PartialReflect` without a valid `to_dynamic` or `reflect_clone` method. ## Testing You can test locally using the following command: ``` cargo test --package bevy_reflect --all-features ``` --- ## Migration Guide `PartialReflect::clone_value` is being deprecated. Instead, use `PartialReflect::to_dynamic` if wanting to create a new dynamic instance of the reflected value. Alternatively, use `PartialReflect::reflect_clone` to attempt to create a true clone of the underlying value. Similarly, the following methods have been deprecated and should be replaced with these alternatives: - `Array::clone_dynamic` → `Array::to_dynamic_array` - `Enum::clone_dynamic` → `Enum::to_dynamic_enum` - `List::clone_dynamic` → `List::to_dynamic_list` - `Map::clone_dynamic` → `Map::to_dynamic_map` - `Set::clone_dynamic` → `Set::to_dynamic_set` - `Struct::clone_dynamic` → `Struct::to_dynamic_struct` - `Tuple::clone_dynamic` → `Tuple::to_dynamic_tuple` - `TupleStruct::clone_dynamic` → `TupleStruct::to_dynamic_tuple_struct`
Fix moire artifacts in bevyengine#16635. Default directional light biases are overkill but it's fine.
# Objective Installment of the bevyengine#16547 series. The vast majority of uses for these types will be the `Entity` case, so it makes sense for it to be the default. ## Solution `UniqueEntityVec`, `UniqueEntitySlice`, `UniqueEntityArray` and their helper iterator aliases now have `Entity` as a default. Unfortunately, this means the the `T` parameter for `UniqueEntityArray` now has to be ordered after the `N` constant, which breaks the consistency to `[T; N]`. Same with about a dozen iterator aliases that take some `P`/`F` predicate/function parameter. This should however be an ergonomic improvement in most cases, so we'll just have to live with this inconsistency. ## Migration Guide Switch type parameter order for the relevant wrapper types/aliases.
…Image> (bevyengine#18326) Less data accessed and compared gives better batching performance. # Objective - Use a smaller id to represent the lightmap in batch data to enable a faster implementation of draw streams. - Improve batching performance for 3D sorted render phases. ## Solution - 3D batching can use `LightmapSlabIndex` (a `NonMaxU32` which is 4 bytes) instead of the lightmap `AssetId<Image>` (an enum where the largest variant is a 16-byte UUID) to discern the ability to batch. ## Testing Tested main (yellow) vs this PR (red) on an M4 Max using the `many_cubes` example with `WGPU_SETTINGS_PRIO=webgl2` to avoid GPU-preprocessing, and modifying the materials in `many_cubes` to have `AlphaMode::Blend` so that they would rely on the less efficient sorted render phase batching. <img width="1500" alt="Screenshot_2025-03-15_at_12 17 21" src="https://github.com/user-attachments/assets/14709bd3-6d06-40fb-aa51-e1d2d606ebe3" /> A 44.75us or 7.5% reduction in median execution time of the batch and prepare sorted render phase system for the `Transparent3d` phase (handling 160k cubes). --- ## Migration Guide - Changed: `RenderLightmap::new()` no longer takes an `AssetId<Image>` argument for the asset id of the lightmap image.
Fix bevyengine#17763. Attachment info needs to be created outside of the command encoding task, as it needs to be part of the serial node runners in order to get the ordering correct.
…g arrays aren't supported. (bevyengine#18126) I mistakenly thought that with the wgpu upgrade we'd have `PARTIALLY_BOUND_BINDING_ARRAY` everywhere. Unfortunately this is not the case. This PR adds a workaround back in. Closes bevyengine#18098.
# Objective - Fixes bevyengine#18331 ## Solution - Add some info on other tools that `cargo timings`
…engine#18335) # Objective I was setting up an asset loader that passes settings through to `ImageLoader`, and i have to clone the settings to achieve this. ## Solution Derive `Clone` for `ImageLoaderSettings` and `ImageFormatSetting`. ## Testing Full CI passed.
…18198) Registering dynamic bundles was not possible for the user yet. It is alone not very useful though as there are no methods to clone, move or remove components via a `BundleId`. This could be a follow-up work if this PR is approved and such a third (besides `T: Bundle` and `ComponentId`(s)) API for structural operation is desired. I certainly would use a hypothetical `EntityClonerBuilder::allow_by_bundle_id`. I personally still would like this register method because I have a `Bundles`-like custom data structure and I would like to not reinvent the wheel. Then instead of having boxed `ComponentId` slices in my collection I could look up explicit and required components there. For reference scroll up to the typed version right above the new one.
…18336) # Objective The `ViewportConversionError` error type does not implement `Error`, making it incompatible with `BevyError`. ## Solution Derive `Error` for `ViewportConversionError`. I chose to use `thiserror` since it's already a dependency, but do let me know if we should be preferring `derive_more`. ## Testing You can test this by trying to compile the following: ```rust let error: BevyError = ViewportConversionError::InvalidData.into(); ```
# Objective - super-linter uses an old version in CI and wasn't updated for the last two years ## Solution - Update super-linter
…vyengine#18345) # Objective - Fixes bevyengine#18342. ## Solution - Canonicalize the root path so that when we try to strip the prefix, it matches the canonicalized asset path. - This is basically just a followup to bevyengine#18023. ## Testing - Ran the hot_asset_reloading example and it no longer panics.
# Objective Continuation to bevyengine#16547 and bevyengine#17954. The `get_many` family are the last methods on `Query`/`QueryState` for which we're still missing a `unique` version. ## Solution Offer `get_many_unique`/`get_many_unique_mut` and `get_many_unique_inner`! Their implementation is the same as `get_many`, the difference lies in their guaranteed-to-be unique inputs, meaning we never do any aliasing checks. To reduce confusion, we also rename `get_many_readonly` into `get_many_inner` and the current `get_many_inner` into `get_many_mut_inner` to clarify their purposes. ## Testing Doc examples. ## Migration Guide `get_many_inner` is now called `get_many_mut_inner`. `get_many_readonly` is now called `get_many_inner`.
…evyengine#18279) # Objective - Adding process specific cpu/mem usages to SystemInformationDiagnosticsPlugin - Fixes bevyengine#18135 ## Solution - Adding two new stats by using code provided in bevyengine#18135 ## Testing - Tested by adding SystemInformationDiagnosticsPlugin into enabling_disabling_diagnostics example - Tested only on Linux (Ubuntu 24.04.2 LTS) --- ## Showcase Example output: > 2025-03-12T18:20:45.355206Z INFO bevy diagnostic: fps : 144.139984 (avg 143.968838) > 2025-03-12T18:20:45.355229Z INFO bevy diagnostic: system/cpu_usage : 17.299578% (avg 16.410863%) > 2025-03-12T18:20:45.355235Z INFO bevy diagnostic: frame_time : 6.939720ms (avg 6.953508ms) > 2025-03-12T18:20:45.355239Z INFO bevy diagnostic: frame_count : 1271.000000 > 2025-03-12T18:20:45.355243Z INFO bevy diagnostic: process/cpu_usage: 172.151901% (avg 165.337555%) > 2025-03-12T18:20:45.355247Z INFO bevy diagnostic: process/mem_usage: 400.472656% (avg 400.478516%) > 2025-03-12T18:20:45.355250Z INFO bevy diagnostic: system/mem_usage : 34.244571% (avg 34.356289%)
…ssKit (bevyengine#18346) The initial `with_visible` call was intended to do this, but that was undone by a later `with_visible` call.
Bumps [crate-ci/typos](https://github.com/crate-ci/typos) from 1.30.1 to 1.30.2. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/crate-ci/typos/releases">crate-ci/typos's releases</a>.</em></p> <blockquote> <h2>v1.30.2</h2> <h2>[1.30.2] - 2025-03-10</h2> <h3>Features</h3> <ul> <li>Add <code>--highlight-words</code> and <code>--highlight-identifiers</code> for easier debugging of config</li> </ul> </blockquote> </details> <details> <summary>Changelog</summary> <p><em>Sourced from <a href="https://github.com/crate-ci/typos/blob/master/CHANGELOG.md">crate-ci/typos's changelog</a>.</em></p> <blockquote> <h2>[1.30.2] - 2025-03-10</h2> <h3>Features</h3> <ul> <li>Add <code>--highlight-words</code> and <code>--highlight-identifiers</code> for easier debugging of config</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/crate-ci/typos/commit/7bc041cbb7ca9167c9e0e4ccbb26f48eb0f9d4e0"><code>7bc041c</code></a> chore: Release</li> <li><a href="https://github.com/crate-ci/typos/commit/4af8a5a1fbfa8534227a9f8c5404b065179448f9"><code>4af8a5a</code></a> docs: Update changelog</li> <li><a href="https://github.com/crate-ci/typos/commit/ec626a1e534129beb0af521bc3116a4040c56dcd"><code>ec626a1</code></a> Merge pull request <a href="https://github.com/crate-ci/typos/issues/1257">#1257</a> from epage/highlight</li> <li><a href="https://github.com/crate-ci/typos/commit/d06a1dd728d2920754dfa206cbf5722050d252ec"><code>d06a1dd</code></a> feat(cli): Add '--highlight-<identifiers|words>' flags</li> <li>See full diff in <a href="https://github.com/crate-ci/typos/compare/v1.30.1...v1.30.2">compare view</a></li> </ul> </details> <br /> [](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores) Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `@dependabot rebase`. [//]: # (dependabot-automerge-start) [//]: # (dependabot-automerge-end) --- <details> <summary>Dependabot commands and options</summary> <br /> You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually - `@dependabot show <dependency name> ignore conditions` will show all of the ignore conditions of the specified dependency - `@dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) </details> Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
# Objective Fixes bevyengine#16896 Fixes bevyengine#17737 ## Solution Adds a new render phase, including all the new cold specialization patterns, for wireframes. There's a *lot* of regrettable duplication here between 3d/2d. ## Testing All the examples. ## Migration Guide - `WireframePlugin` must now be created with `WireframePlugin::default()`.
…evyengine#18768) # Objective - Improve the docs for `PointLightShadowMap` and `DirectionalLightShadowMap` ## Solution - Add example for how to use `PointLightShadowMap` and move the `DirectionalLightShadowMap` example from `DirectionalLight`. - Match `PointLight` and `DirectionalLight` docs about shadows. - Describe what `size` means. --------- Co-authored-by: Robert Swain <[email protected]>
# Objective - Fixes bevyengine#18780 ## Solution - Add `?` ## Testing - CI --- ## Notes _smol_
A clippy failure slipped into bevyengine#18768, although I'm not sure why CI didn't catch it. ```sh > cargo clippy --version clippy 0.1.85 (4eb161250e 2025-03-15) > cargo run -p ci ... error: empty line after doc comment --> crates\bevy_pbr\src\light\mod.rs:105:5 | 105 | / /// The width and height of each of the 6 faces of the cubemap. 106 | | | |_^ | = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#empty_line_after_doc_comments = note: `-D clippy::empty-line-after-doc-comments` implied by `-D warnings` = help: to override `-D warnings` add `#[allow(clippy::empty_line_after_doc_comments)]` = help: if the empty line is unintentional remove it help: if the documentation should include the empty line include it in the comment | 106 | /// | ```
…18794) # Objective - I've worked on the migration guide in the past, so I've written down some of the conventions and styles I've used. ## Solution Please read through the descriptions of each commit, which justify the change! In summary: - Remove headings from migration guide template by moving style guide to `migration_guides.md` - Use parentheses to signal method and function names (`my_func()` instead of `my_func`) - Change the guidelines on using bullet points so they're not used for every single migration guide. - Remove suggestion to use diff blocks, as they don't syntax-highlight Rust code. --------- Co-authored-by: Rob Parrett <[email protected]> Co-authored-by: Miles Silberling-Cook <[email protected]> Co-authored-by: Alice Cecile <[email protected]>
…ExitCondition` (bevyengine#18438) # Objective - The referenced `ScheduleLabel` for `OnPrimaryClosed` and `OnAllClosed` in `ExitCondition` was incorrect ## Solution - Changed `Update` to `PostUpdate`
# Objective Fixes bevyengine#18795 ## Solution Ignore RenderEntity during entity clones
# Objective - Piped systems are an edge case that we missed when reworking system parameter validation. - Fixes bevyengine#18755. ## Solution - Validate the parameters for both systems, ~~combining the errors if both failed validation~~ by simply using an early out. - ~~Also fix the same bug for combinator systems while we're here.~~ ## Testing I've added a large number of tests checking the behavior under various permutations. These are separate tests, rather than one mega test because a) it's easier to track down bugs that way and b) many of these are `should_panic` tests, which will halt the evaluation of the rest of the test! I've also added a test for exclusive systems being pipeable because we don't have one and I was very surprised that that works! --------- Co-authored-by: Chris Russell <[email protected]>
Fixes bevyengine#17591 Looking at the arm downloads page, "r48p0" is a version number that increments, where rXX is the major version and pX seems to be a patch version. Take the conservative approach here that we know gpu preprocessing is working on at least version 48 and presumably higher. The assumption here is that the driver_info string will be reported similarly on non-pixel devices.
# Objective - Fixes bevyengine#18781 ## Solution - Moved `LogPlugin` into its own file gated behind a new `tracing` feature. - Used `log` instead of `tracing` where possible. - Exposed a new `tracing` feature in `bevy` which enables `bevy_log/tracing`. - Gated `LogPlugin` from `DefaultPlugins` on `tracing` feature. ## Testing - CI --- ## Migration Guide - If you were previously using `bevy_log` with default features disabled, enable the new `std` and `tracing` features. - If you were using `bevy` with the default features disabled, enable the new `tracing` feature. ## Notes Almost all of the diffs in this PR come from moving `LogPlugin` into its own file. This just makes the PR less noisy, since the alternative is excessive `#[cfg(feature = "tracing")]` directives all over the plugin. --------- Co-authored-by: François Mockers <[email protected]>
# Objective - `bevy_dylib` currently doesn't build independently ``` cargo build -p bevy_dylib Compiling bevy_dylib v0.16.0-rc.4 (/crates/bevy_dylib) error: no global memory allocator found but one is required; link to std or add `#[global_allocator]` to a static item that implements the GlobalAlloc trait error: `#[panic_handler]` function required, but not found error: unwinding panics are not supported without std | = help: using nightly cargo, use -Zbuild-std with panic="abort" to avoid unwinding = note: since the core library is usually precompiled with panic="unwind", rebuilding your crate with panic="abort" may not be enough to fix the problem error: could not compile `bevy_dylib` (lib) due to 3 previous errors ``` ## Solution - remove `#![no_std]` from `bevy_dylib` ## Testing - it builds now
# Objective The goal of `bevy_platform_support` is to provide a set of platform agnostic APIs, alongside platform-specific functionality. This is a high traffic crate (providing things like HashMap and Instant). Especially in light of bevyengine#18799, it deserves a friendlier / shorter name. Given that it hasn't had a full release yet, getting this change in before Bevy 0.16 makes sense. ## Solution - Rename `bevy_platform_support` to `bevy_platform`.
…vyengine#18814) # Objective Fixes bevyengine#18808 ## Solution When an asset emits a removed event, mark it as modified in the render world to ensure any appropriate bookkeeping runs as necessary.
…engine#18836) Fixes bevyengine#18809 Fixes bevyengine#18823 Meshes despawned in `Last` can still be in visisible entities if they were visible as of `PostUpdate`. Sanity check that the mesh actually exists before we specialize. We still want to unconditionally assume that the entity is in `EntitySpecializationTicks` as its absence from that cache would likely suggest another bug.
The parameter `In` of `call_inner` is completely unconstrained by its arguments and return type. We are only able to infer it by assuming that the only associated type equal to `In::Param<'_>` is `In::Param<'_>` itself. It could just as well be some other associated type which only normalizes to `In::Param<'_>`. This will change with the next-generation trait solver and was encountered by a crater run rust-lang/rust#133502 cc rust-lang/trait-system-refactor-initiative#168 I couldn't think of a cleaner alternative here. I first tried to just provide `In` as an explicit type parameter. This is also kinda ugly as I need to provide a variable number of them and `${ignore(..)}` is currently still unstable rust-lang/rust#83527. Sorry for the inconvenience. Also fun that this function exists to avoid a separate solver bug in the first place 😅
…raits (bevyengine#18804) # Objective After bevyengine#17967, closures which always panic no longer satisfy various Bevy traits. Principally, this affects observers, systems and commands. While this may seem pointless (systems which always panic are kind of useless), it is distinctly annoying when using the `todo!` macro, or when writing tests that should panic. Fixes bevyengine#18778. ## Solution - Add failing tests to demonstrate the problem - Add the trick from [`never_say_never`](https://docs.rs/never-say-never/latest/never_say_never/) to name the `!` type on stable Rust - Write looots of docs explaining what the heck is going on and why we've done this terrible thing ## To do Unfortunately I couldn't figure out how to avoid conflicting impls, and I am out of time for today, the week and uh the week after that. Vacation! If you feel like finishing this for me, please submit PRs to my branch and I can review and press the button for it while I'm off. Unless you're Cart, in which case you have write permissions to my branch! - [ ] fix for commands - [ ] fix for systems - [ ] fix for observers - [ ] revert bevyengine/bevy-website#2092 ## Testing I've added a compile test for these failure cases and a few adjacent non-failing cases (with explicit return types). --------- Co-authored-by: Carter Anderson <[email protected]>
…#18824) Fixes a small mix-up from bevyengine#18058, which added bulk relationship replacement methods. `EntityCommands::replace_related_with_difference` calls `EntityWorldMut::replace_children_with_difference` instead of `EntityWorldMut::replace_related_with_difference`, which means it always operates on the `ChildOf` relationship instead of the `R: Relationship` generic it's provided. `EntityCommands::replace_children_with_difference` takes an `R: Relationship` generic that it shouldn't, but it accidentally works correctly on `main` because it calls the above method.
# Objective I was wrong about how RPITIT works when I wrote this stuff initially, and in order to actually give people access to all the traits implemented by the output (e.g. Debug and so on) it's important to expose the real output type, even if it makes the trait uglier and less comprehensible. (☹️ ) ## Solution Expose the curve output type of the `CurveWithDerivative` trait and its double-derivative companion. I also added a bunch of trait derives to `WithDerivative<T>`, since I think that was just an oversight.
bevyengine#18828) The purpose of the scene viewer is to load arbitrary glTF scenes, so it's inconvenient if they have to be moved into the Bevy assets directory first. Thus this patch switches the scene viewer to use `UnapprovedPathMode::Allow`. --------- Co-authored-by: François Mockers <[email protected]>
…ntityCommands` (bevyengine#18835) Fixes bevyengine#18834. `EntityWorldMut::remove_children` and `EntityCommands::remove_children` were removed in the relationships overhaul (bevyengine#17398) and never got replaced. I don't *think* this was intentional (the methods were never mentioned in the PR or its comments), but I could've missed something.
…18782)" (bevyengine#18816) This reverts commit ac52cca. Fixes bevyengine#18815 # Objective bevyengine#18782 resulted in using `log` macros instead of `tracing` macros (in the interest of providing no_std support, specifically no_atomic support). That tradeoff isn't worth it, especially given that tracing is likely to get no_atomic support. ## Solution Revert bevyengine#18782
…engine#18825) There's still a race resulting in blank materials whenever a material of type A is added on the same frame that a material of type B is removed. PR bevyengine#18734 improved the situation, but ultimately didn't fix the race because of two issues: 1. The `late_sweep_material_instances` system was never scheduled. This PR fixes the problem by scheduling that system. 2. `early_sweep_material_instances` needs to be called after *every* material type has been extracted, not just when the material of *that* type has been extracted. The `chain()` added during the review process in PR bevyengine#18734 broke this logic. This PR reverts that and fixes the ordering by introducing a new `SystemSet` that contains all material extraction systems. I also took the opportunity to switch a manual reference to `AssetId::<StandardMaterial>::invalid()` to the new `DUMMY_MESH_MATERIAL` constant for clarity. Because this is a bug that can affect any application that switches material types in a single frame, I think this should be uplifted to Bevy 0.16.
# Objective One to one relationships (added in bevyengine#18087) can currently easily be invalidated by having two entities relate to the same target. Alternative to bevyengine#18817 (removing one-to-one relationships) ## Solution Panic if a RelationshipTarget is already targeted. Thanks @urben1680 for the idea! --------- Co-authored-by: François Mockers <[email protected]>
This reverts commit a9b0b4e.
…evyengine#18846) # Objective Fixes bevyengine#18843 ## Solution We need to account for the material being added and removed in the course of the same frame. We evict the caches first because the entity will be re-added if it was marked as needing specialization, which avoids another check on removed components to see if it was "really" despawned.
# Objective - Fixes bevyengine#18890 ## Solution - Don't overflow when substracting, bound at 0 ## Testing - Reproducer from the issue now works
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
77 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Original PR: bevyengine#16885
This is a test to see how Codspeed reacts to benchmarking pull requests.