Resolve merge conflicts in lienar-rgba-everywhere
#166
Conversation
This file contains 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
# Objective Pretty minor change to add `Debug` to `Has`. This is helpful for users (Like me) who have the [`missing_debug_implementations`](https://doc.rust-lang.org/stable/nightly-rustc/rustc_lint/builtin/static.MISSING_DEBUG_IMPLEMENTATIONS.html) lint turned on. ## Solution Simple `#[derive(Debug)]` ## Changelog * Has now implemented `Debug`
# Objective - Fixes bevyengine#12677 ## Solution Updated documentation to make it explicit that enabling the appropriate optional features is required to use the supported audio file format, as well as provided link to the Bevy docs listing the optional features. Co-authored-by: Alice Cecile <[email protected]>
# Objective - Avoid unbounded HashMap growth for opening/closing windows. ## Solution - Remove map entry in `WinitWindows::remove_window`. ## Migration Guide - `WinitWindows::get_window_entity` now returns `None` after a window is closed, instead of a dead entity. --- ## Comments The comment this PR replaces was added in bevyengine#3575. Since `get_window_entity` now returns an `Entity` instead of a `WindowId`, this no longer seems useful. Note that `get_window_entity` is only used [here](https://github.com/bevyengine/bevy/blob/56bcbb097552b45e3ff48c48947ed8ee4e2c24b1/crates/bevy_winit/src/lib.rs#L436), immediately followed by a warning if the entity returned doesn't exist.
# Objective CI on main has been failing for the following reason: ``` error[E0636]: the feature `doc_auto_cfg` has already been declared --> src/lib.rs:48:29 | 48 | #![cfg_attr(docsrs, feature(doc_auto_cfg))] | ^^^^^^^^^^^^ ``` ## Solution Remove the redundant attribute.
# Objective - Move `PanicHandlerPlugin` into `bevy_app` - Fixes bevyengine#12603 . ## Solution - I moved the `bevy_panic_handler` into `bevy_app` - Copy pasted `bevy_panic_handler`'s lib.rs into a separate module in `bevy_app` as a `panic_handler.rs` module file and added the `PanicHandlerPlugin` in lib.rs of `bevy_app` - added the dependency into `cargo.toml` ## Review notes - I probably want some feedback if I imported App and Plugin correctly in `panic_handler.rs` line 10 and 11. - As of yet I have not deleted `bevy_panic_handler` crate, wanted to get a check if I added it correctly. - Once validated that my move was correct, I'll probably have to remove the panic handler find default plugins which I probably need some help to find. - And then remove bevy panic_handler and making sure ci passes. - This is my first issue for contributing to bevy so let me know if I am doing anything wrong. ## tools context - rust is 1.76 version - Windows 11 --------- Co-authored-by: Alice Cecile <[email protected]>
# Objective Fix bevyengine#12728. Fix unsoundnesss from unhandled null characters in Android logs. ## Solution Use `CString` instead of using formatted Strings. Properly document the safety invariants of the FFI call.
# Objective - Closes bevyengine#12415 ## Solution - Refactored code that was changed/deprecated in `image` 0.25. - Please review this PR carefully since I'm just making the changes without any context or deep knowledge of the module. --------- Signed-off-by: dependabot[bot] <[email protected]> Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com> Co-authored-by: James Liu <[email protected]>
# Objective Fixes bevyengine#12392, fixes bevyengine#12393, and fixes bevyengine#11387. Implement QueryData for Archetype and EntityLocation. ## Solution Add impls for both of the types. --- ## Changelog Added: `&Archetype` now implements `QueryData` Added: `EntityLocation` now implements `QueryData` --------- Co-authored-by: Alice Cecile <[email protected]>
…riangle (bevyengine#12766) # Objective When I wrote bevyengine#12747 I neglected to translate random samples from triangles back to the point where they originated, so they would be sampled near the origin instead of at the actual triangle location. ## Solution Translate by the first vertex location so that the samples follow the actual triangle.
…s deleted (bevyengine#12710) # Objective - A scene usually gets created using the `SceneBundle` or `DynamicSceneBundle`. This means that the scene's entities get added as children of the root entity (the entity on which the `SceneBundle` gets added) - When the scene gets deleted using the `SceneSpawner`, the scene's entities are deleted, but the `Children` component of the root entity doesn't get updated. This means that the hierarchy becomes unsound, with Children linking to non-existing components. ## Solution - Update the `despawn_sync` logic to also update the `Children` from any parents of the scene, if there are any - Adds a test where a Scene gets despawned and checks for dangling Children references on the parent. The test fails on `main` but works here. ## Alternative implementations - One option could be to add a `parent: Option<Entity>` on the [InstanceInfo](https://github.com/bevyengine/bevy/blob/df15cd7dcc09869f7ce9c7865378591b91b31749/crates/bevy_scene/src/scene_spawner.rs#L27) struct that tracks if the SceneInstance was added as a child of a root entity
# Objective Fixes bevyengine#12727. All parts that `PersistentGpuBuffer` interact with should be 100% safe both on the CPU and the GPU: `Queue::write_buffer_with` zeroes out the slice being written to and when uploading to the GPU, and all slice writes are bounds checked on the CPU side. ## Solution Make `PersistentGpuBufferable` a safe trait. Enforce it's correct implementation via assertions. Re-enable `forbid(unsafe_code)` on `bevy_pbr`.
# Objective Fix bevyengine#12764. ## Solution Implement Clone for the type.
…ate) (bevyengine#12776) # Objective Fixes bevyengine#12752. Fixes bevyengine#12750. Document the runtime complexity of all of the `O(1)` operations on the individual APIs. ## Solution * Mirror `Query::contains` onto `QueryState::contains` * Make `QueryState::as_nop` pub(crate) * Make `NopWorldQuery` pub(crate) * Document all of the O(1) operations on Query and QueryState.
# Objective - Disabling some plugins causes a crash due to ambiguities relying in feature flags and not checking if both plugins are enabled causing code like this to crash: `app.add_plugins(DefaultPlugins.build().disable::<AnimationPlugin>())` ## Solution - Check if plugins were added before ambiguities. - Move bevy_gizmos ambiguities from bevy_internal to bevy_gizmos since they already depend on them.
# Objective - Reduce the size of `create_windows` and isolate accessibility setup logic. ## Solution - Move accessibility setup for new windows to the `accessibility` module. ## Comments This is a small refactor, no behavior changes.
# Objective - Allow cloning `WinitSettings`. I use this in [bevy_worldswap](https://github.com/UkoeHB/bevy_worldswap) when synchronizing secondary app window state. ## Solution - Add `Clone` to `WinitSettings`. --- ## Changelog - Added `Clone` to `WinitSettings`.
# Objective Wireframes are currently supported for 3D meshes using the `WireframePlugin` in `bevy_pbr`. This PR adds the same functionality for 2D meshes. Closes bevyengine#5881. ## Solution Since there's no easy way to share material implementations between 2D, 3D, and UI, this is mostly a straight copy and rename from the original plugin into `bevy_sprite`. <img width="1392" alt="image" src="https://github.com/bevyengine/bevy/assets/3961616/7aca156f-448a-4c7e-89b8-0a72c5919769"> --- ## Changelog - Added `Wireframe2dPlugin` and related types to support 2D wireframes. - Added an example to demonstrate how to use 2D wireframes --------- Co-authored-by: IceSentry <[email protected]>
…cture. (bevyengine#12783) This commit changes the `StandardMaterialKey` to be based on a set of bitflags instead of a structure. We hash it every frame for every mesh, and `#[derive(Hash)]` doesn't generate particularly efficient code for large structures full of small types. Packing it into a single `u64` therefore results in a roughly 10% speedup in `queue_material_meshes` on `many_cubes --no-frustum-culling`. 
# Objective - Primitive meshing is suboptimal - Improve primitive meshing ## Solution - Add primitive meshing benchmark - Allows measuring future improvements --- First of a few PRs to refactor and improve primitive meshing.
Created soundtrack example, fade-in and fade-out features, added new assets, and updated credits. # Objective - Fixes bevyengine#12651 ## Solution - Created a resource to hold the track list. - The audio assets are then loaded by the asset server and added to the track list. - Once the game is in a specific state, an `AudioBundle` is spawned and plays the appropriate track. - The audio volume starts at zero and is then incremented gradually until it reaches full volume. - Once the game state changes, the current track fades out, and a new one fades in at the same time, offering a relatively seamless transition. - Once a track is completely faded out, it is despawned from the app. - Game state changes are simulated through a `Timer` for simplicity. - Track change system is only run if there is a change in the `GameState` resource. - All tracks are used according to their respective licenses. --------- Co-authored-by: Alice Cecile <[email protected]>
…ng them. (bevyengine#12453) Today, we sort all entities added to all phases, even the phases that don't strictly need sorting, such as the opaque and shadow phases. This results in a performance loss because our `PhaseItem`s are rather large in memory, so sorting is slow. Additionally, determining the boundaries of batches is an O(n) process. This commit makes Bevy instead applicable place phase items into *bins* keyed by *bin keys*, which have the invariant that everything in the same bin is potentially batchable. This makes determining batch boundaries O(1), because everything in the same bin can be batched. Instead of sorting each entity, we now sort only the bin keys. This drops the sorting time to near-zero on workloads with few bins like `many_cubes --no-frustum-culling`. Memory usage is improved too, with batch boundaries and dynamic indices now implicit instead of explicit. The improved memory usage results in a significant win even on unbatchable workloads like `many_cubes --no-frustum-culling --vary-material-data-per-instance`, presumably due to cache effects. Not all phases can be binned; some, such as transparent and transmissive phases, must still be sorted. To handle this, this commit splits `PhaseItem` into `BinnedPhaseItem` and `SortedPhaseItem`. Most of the logic that today deals with `PhaseItem`s has been moved to `SortedPhaseItem`. `BinnedPhaseItem` has the new logic. Frame time results (in ms/frame) are as follows: | Benchmark | `binning` | `main` | Speedup | | ------------------------ | --------- | ------- | ------- | | `many_cubes -nfc -vpi` | 232.179 | 312.123 | 34.43% | | `many_cubes -nfc` | 25.874 | 30.117 | 16.40% | | `many_foxes` | 3.276 | 3.515 | 7.30% | (`-nfc` is short for `--no-frustum-culling`; `-vpi` is short for `--vary-per-instance`.) --- ## Changelog ### Changed * Render phases have been split into binned and sorted phases. Binned phases, such as the common opaque phase, achieve improved CPU performance by avoiding the sorting step. ## Migration Guide - `PhaseItem` has been split into `BinnedPhaseItem` and `SortedPhaseItem`. If your code has custom `PhaseItem`s, you will need to migrate them to one of these two types. `SortedPhaseItem` requires the fewest code changes, but you may want to pick `BinnedPhaseItem` if your phase doesn't require sorting, as that enables higher performance. ## Tracy graphs `many-cubes --no-frustum-culling`, `main` branch: <img width="1064" alt="Screenshot 2024-03-12 180037" src="https://github.com/bevyengine/bevy/assets/157897/e1180ce8-8e89-46d2-85e3-f59f72109a55"> `many-cubes --no-frustum-culling`, this branch: <img width="1064" alt="Screenshot 2024-03-12 180011" src="https://github.com/bevyengine/bevy/assets/157897/0899f036-6075-44c5-a972-44d95895f46c"> You can see that `batch_and_prepare_binned_render_phase` is a much smaller fraction of the time. Zooming in on that function, with yellow being this branch and red being `main`, we see: <img width="1064" alt="Screenshot 2024-03-12 175832" src="https://github.com/bevyengine/bevy/assets/157897/0dfc8d3f-49f4-496e-8825-a66e64d356d0"> The binning happens in `queue_material_meshes`. Again with yellow being this branch and red being `main`: <img width="1064" alt="Screenshot 2024-03-12 175755" src="https://github.com/bevyengine/bevy/assets/157897/b9b20dc1-11c8-400c-a6cc-1c2e09c1bb96"> We can see that there is a small regression in `queue_material_meshes` performance, but it's not nearly enough to outweigh the large gains in `batch_and_prepare_binned_render_phase`. --------- Co-authored-by: James Liu <[email protected]>
# Objective Speed up CPU-side rendering. ## Solution Use `QueryIter::for_each` and `Mut::bypass_change_detection` to minimize the total amount of data being written and allow autovectorization to speed up iteration. ## Performance Tested against the default `many_cubes`, this results in greater than 15x speed up: 281us -> 18.4us.  As `ViewVisibility::HIDDEN` just wraps false, this is likely just degenerating into `memset(0)`s on the tables.
# Objective Other than the exposed functions for reading matched tables and archetypes, a `QueryState` does not actually need both internal Vecs for storing matched archetypes and tables. In practice, it will only use one of the two depending on if it uses dense or archetypal iteration. Same vein as bevyengine#12474. The goal is to reduce the memory overhead of using queries, which Bevy itself, ecosystem plugins, and end users are already fairly liberally using. ## Solution Add `StorageId`, which is a union over `TableId` and `ArchetypeId`, and store only one of the two at runtime. Read the slice as if it was one ID depending on whether the query is dense or not. This follows in the same vein as bevyengine#5085; however, this one directly impacts heap memory usage at runtime, while bevyengine#5085 primarily targeted transient pointers that might not actually exist at runtime. --- ## Changelog Changed: `QueryState::matched_tables` now returns an iterator instead of a reference to a slice. Changed: `QueryState::matched_archetypes` now returns an iterator instead of a reference to a slice. ## Migration Guide `QueryState::matched_tables` and `QueryState::matched_archetypes` does not return a reference to a slice, but an iterator instead. You may need to use iterator combinators or collect them into a Vec to use it as a slice. --------- Co-authored-by: Alice Cecile <[email protected]>
- Fixes #[12762](bevyengine#12762). ## Migration Guide - `Quat` no longer implements `VectorSpace` as unit quaternions don't actually form proper vector spaces. If you're absolutely certain that what you're doing is correct, convert the `Quat` into a `Vec4` and perform the operations before converting back.
# Objective - Fix bevyengine#12746 - When users despawn a scene, the `InstanceId` within `spawned_scenes` and `spawned_dynamic_scenes` is not removed, causing a potential memory leak ## Solution - `spawned_scenes` field was never used, and I removed it - Add a component remove hook for `Handle<DynamicScene>`, and when the `Handle<DynamicScene>` component is removed, delete the corresponding `InstanceId` from `spawned_dynamic_scenes`
…ders (bevyengine#12547) # Objective For some asset loaders, it can be useful not to read the entire asset file and just read a specific region of a file. For this, we need a way to seek at a specific position inside the file ## Solution I added support for `AsyncSeek` to `Reader`. In my case, I want to only read a part of a file, and for that I need to seek to a specific point. ## Migration Guide Every custom reader (which previously only needed the `AsyncRead` trait implemented) now also needs to implement the `AsyncSeek` trait to add the seek capability.
… how to make it work for 2d (bevyengine#12775) # Objective - `examples/shader/post_processing.rs` is a shader example that works for 3d - I recently tried to update this example to get it to work on 2d but failed to do so - Then I created a discord help thread to help me figure this out. [here's the link to the thread](https://discordapp.com/channels/691052431525675048/1221819669116354723). ## Solution - The solution is to replace all instances of 3d structures with their respective 2d counterparts ## Changelog - Added a small comment that explains how to get the example to work on 2d #### Please do suggest changes if any --------- Co-authored-by: IceSentry <[email protected]>
# Objective Fix crashing on Linux with latest stable Nvidia 550 driver when resizing. The crash happens at startup with some setups. Fixes bevyengine#12199 I think this would be nice to get into 0.13.1 ## Solution Ignore `wgpu::SurfaceError::Outdated` always on this platform+driver. It looks like Nvidia considered the previous behaviour of not returning this error a bug: "Fixed a bug where vkAcquireNextImageKHR() was not returning VK_ERROR_OUT_OF_DATE_KHR when it should with WSI X11 swapchains" (https://www.nvidia.com/Download/driverResults.aspx/218826/en-us/) What I gather from this is that the surface was outdated on previous drivers too, but they just didn't report it as an error. So behaviour shouldn't change. In the issue conversation we experimented with calling `continue` when this error happens, but I found that it results in some small issues like bevy_egui scale not updating with the window sometimes. Just doing nothing seems to work better. ## Changelog - Fixed crashing on Linux with Nvidia 550 driver when resizing the window ## Migration Guide --------- Co-authored-by: James Liu <[email protected]>
# Objective Get an early warning if any new rust lints will break CI. Closes bevyengine#12625 ## Solution Test the main branch against the Rust beta every week. ## Additional Possibilities The action currently creates an issue if anything fails. The issue could use a label like `C-Weekly` but somebody with the ability to create issue labels would have to add it. Another possibility would be to use discord webhooks. That would need somebody with the access to create webhooks on discord and somebody with the rights to connect that webhook to this repo,
…ne#9202) # Objective This is a necessary precursor to bevyengine#9122 (this was split from that PR to reduce the amount of code to review all at once). Moving `!Send` resource ownership to `App` will make it unambiguously `!Send`. `SubApp` must be `Send`, so it can't wrap `App`. ## Solution Refactor `App` and `SubApp` to not have a recursive relationship. Since `SubApp` no longer wraps `App`, once `!Send` resources are moved out of `World` and into `App`, `SubApp` will become unambiguously `Send`. There could be less code duplication between `App` and `SubApp`, but that would break `App` method chaining. ## Changelog - `SubApp` no longer wraps `App`. - `App` fields are no longer publicly accessible. - `App` can no longer be converted into a `SubApp`. - Various methods now return references to a `SubApp` instead of an `App`. ## Migration Guide - To construct a sub-app, use `SubApp::new()`. `App` can no longer convert into `SubApp`. - If you implemented a trait for `App`, you may want to implement it for `SubApp` as well. - If you're accessing `app.world` directly, you now have to use `app.world()` and `app.world_mut()`. - `App::sub_app` now returns `&SubApp`. - `App::sub_app_mut` now returns `&mut SubApp`. - `App::get_sub_app` now returns `Option<&SubApp>.` - `App::get_sub_app_mut` now returns `Option<&mut SubApp>.`
# Objective - `MeshPipelineKey` use some bits for two things - First commit in this PR adds an assertion that doesn't work currently on main - This leads to some mesh topology not working anymore, for example `LineStrip` - With examples `lines`, there should be two groups of lines, the blue one doesn't display currently ## Solution - Change the `MeshPipelineKey` to be backed by a `u64` instead, to have enough bits
Adjusted the documentation to better describe the performance cost of `ButtonInput::any_just_pressed|any_just_released|any_pressed`. Each function iterates the full input, but each check is expected constant cost. It was described previously as a full input check, and a full internal list iteration, which I believe is incorrect.
# Objective Makes crate module docs render correctly in the docs for the monolithic library. Fixes bevyengine#13055. ## Solution Swap from ```rust pub mod foo { pub use bevy_foo::*; } ``` to ```rust pub use bevy_foo as foo; ```
Bumps [crate-ci/typos](https://github.com/crate-ci/typos) from 1.20.8 to 1.20.9. <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.20.9</h2> <h2>[1.20.9] - 2024-04-16</h2> <h3>Fixes</h3> <ul> <li>Don't correct the unit <code>dBA</code> (as an identifier to limit to that case)</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.20.9] - 2024-04-16</h2> <h3>Fixes</h3> <ul> <li>Don't correct the unit <code>dBA</code> (as an identifier to limit to that case)</li> </ul> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/crate-ci/typos/commit/44548ad17abdc3e4ebfa53252764e3ff21dbfa0f"><code>44548ad</code></a> chore: Release</li> <li><a href="https://github.com/crate-ci/typos/commit/73fb2cad756df30f27730df4ec7abb6e8088f682"><code>73fb2ca</code></a> docs: Update changelog</li> <li><a href="https://github.com/crate-ci/typos/commit/21838b0e7d8402e8ede4de677fbfb84b6e226d5e"><code>21838b0</code></a> Merge pull request <a href="https://redirect.github.com/crate-ci/typos/issues/1000">#1000</a> from epage/dba</li> <li><a href="https://github.com/crate-ci/typos/commit/ee32d77aba122c27b38006345490647394f2b699"><code>ee32d77</code></a> fix(dict): Don't correct dBA</li> <li><a href="https://github.com/crate-ci/typos/commit/56df0bd8d66ef3cc9f4c7e99f0b228cc5ff8dd47"><code>56df0bd</code></a> test(dict): Show dBA behavior</li> <li>See full diff in <a href="https://github.com/crate-ci/typos/compare/v1.20.8...v1.20.9">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 Allow parallel iteration over events, resolve bevyengine#10766 ## Solution - Add `EventParIter` which works similarly to `QueryParIter`, implementing a `for_each{_with_id}` operator. I chose to not mirror `EventIteratorWithId` and instead implement both operations on a single struct. - Reuse `BatchingStrategy` from `QueryParIter` ## Changelog - `EventReader` now supports parallel event iteration using `par_read().for_each(|event| ...)`. --------- Co-authored-by: James Liu <[email protected]> Co-authored-by: Pablo Reinhardt <[email protected]>
# Objective Add support so bevy_ui can correctly handle an UI hierarchy without a camera present. - Fixes bevyengine#12184 ## Solution As there was no default behavior for what should happen when a camera is not present in a UI hierarchy, the solution was based in defining that default behavior and improving the overall handling of this "exception". ## Changelog - Create default values to be used in upsert_node - Add flag to control warnings about no camera present - Create unit test no_camera_ui (to test if ui handles no camera present)
# Objective - rust-lang/rust#123905 has been merged, so the workaround introduced in bevyengine#12913 is no longer necessary. - Closes bevyengine#12968 ## Solution - Remove unecessary `allow` attribute - This is currently blocked until Rust beta updates. - Last tested with `rustc 1.78.0-beta.7 (6fd191292 2024-04-12)`.
# Objective Closes bevyengine#13017. ## Solution - Make `AppExit` a enum with a `Success` and `Error` variant. - Make `App::run()` return a `AppExit` if it ever returns. - Make app runners return a `AppExit` to signal if they encountered a error. --- ## Changelog ### Added - [`App::should_exit`](https://example.org/) - [`AppExit`](https://docs.rs/bevy/latest/bevy/app/struct.AppExit.html) to the `bevy` and `bevy_app` preludes, ### Changed - [`AppExit`](https://docs.rs/bevy/latest/bevy/app/struct.AppExit.html) is now a enum with 2 variants (`Success` and `Error`). - The app's [runner function](https://docs.rs/bevy/latest/bevy/app/struct.App.html#method.set_runner) now has to return a `AppExit`. - [`App::run()`](https://docs.rs/bevy/latest/bevy/app/struct.App.html#method.run) now also returns the `AppExit` produced by the runner function. ## Migration Guide - Replace all usages of [`AppExit`](https://docs.rs/bevy/latest/bevy/app/struct.AppExit.html) with `AppExit::Success` or `AppExit::Failure`. - Any custom app runners now need to return a `AppExit`. We suggest you return a `AppExit::Error` if any `AppExit` raised was a Error. You can use the new [`App::should_exit`](https://example.org/) method. - If not exiting from `main` any other way. You should return the `AppExit` from `App::run()` so the app correctly returns a error code if anything fails e.g. ```rust fn main() -> AppExit { App::new() //Your setup here... .run() } ``` --------- Co-authored-by: Alice Cecile <[email protected]>
# Objective Fixes bevyengine#12470 This adds a examples for `ButtonInput` with `KeyCode`, `MouseButton`, and `GamepadButton`. It also includes an example of checking a multi-key combination, and checking multiple keys to mean roughly the same thing.
) # Objective Fixes bevyengine#12539 Improve [this CI output](https://github.com/bevyengine/bevy/actions/runs/8367408952/job/22909715870#step:7:11). ## Solution - Don't stop after the first failure. - Print the filename of the patch(es) that failed. - Clean up an unused package install while we're at it. Tested over here: rparrett#20 --------- Co-authored-by: BD103 <[email protected]>
…13065) # Objective Adds a few extra `#[doc(alias)]` entries to the `bevy_math::primitives::WindingOrder` enum and its variants to improve searchability. ## Solution - Add "Orientation" for `WindingOrder` itself - Add "AntiClockwise" for `CounterClockwise` variant - Add "Collinear" for `Invalid` variant These alternate terms seem to be quite common, especially in the contexts of rendering and collision-detection. Signed-off-by: Nullicorn <[email protected]>
Bumps `async-task` to 4.7.0 , note this is what Cargo.lock has as well.
Building as a dependency gives the following:
```
Compiling async-channel v1.8.0
Compiling futures-lite v1.12.0
error[E0432]: unresolved import `async_task::Builder`
--> /Users/daniel/.cargo/registry/src/index.crates.io-6f17d22bba15001f/async-executor-1.8.0/src/lib.rs:46:18
|
46 | use async_task::{Builder, Runnable};
| ^^^^^^^ no `Builder` in the root
|
= help: consider importing this struct instead:
std::thread::Builder
For more information about this error, try `rustc --explain E0432`.
error: could not compile `async-executor` (lib) due to 1 previous error
warning: build failed, waiting for other jobs to finish...
```
With this change, builds correctly
# Objective - Some CI jobs specifically use `macos-14`, as compared to the default `macos-latest`. - `macos-latest` is equivalent to `macos-12`, but may be updated in the future. - The CI job that tests on the minimum supported Rust version (MSRV) uses environmental variables to save the toolchain version. - This specific usage is what step outputs were designed for. - Both do the same thing, but step outputs can be checked by the [Github Actions VSCode Extension](https://marketplace.visualstudio.com/items?itemName=GitHub.vscode-github-actions). - Some workflows have a `NIGHTLY_TOOLCHAIN` variable that let us pin the nightly version, in case a new release breaks CI. ## Solution - Document why certain actions required `macos-14`. - Switch MSRV step to use step outputs. - Add a small comment documenting the purpose of the `NIGHTLY_TOOLCHAIN` environmental variable.
# Objective Allow `Gizmos` to work in `FixedUpdate` without any changes needed. This changes `Gizmos` from being a purely immediate mode api, but allows the user to use it as if it were an immediate mode API regardless of schedule context. Also allows for extending by other custom schedules by adding their own `GizmoStorage<Clear>` and the requisite systems: - `propagate_gizmos::<Clear>` before `update_gizmo_meshes` - `stash_default_gizmos` when starting a clear context - `pop_default_gizmos` when ending a clear context - `collect_default_gizmos` when grabbing the requested gizmos - `clear_gizmos` for clearing the context's gizmos ## Solution Adds a generic to `Gizmos` that defaults to `Update` (the current way gizmos works). When entering a new clear context the default `Gizmos` gets swapped out for that context's duration so the context can collect the gizmos requested. Prior work: bevyengine#9153 ## To do - [x] `FixedUpdate` should probably get its own First, Pre, Update, Post, Last system sets for this. Otherwise users will need to make sure to order their systems before `clear_gizmos`. This could alternatively be fixed by moving the setup of this to `bevy_time::fixed`? PR to fix this issue: bevyengine#10977 - [x] use mem::take internally for the swaps? - [x] Better name for the `Context` generic on gizmos? `Clear`? --- ## Changelog - Gizmos drawn in `FixedMain` now last until the next `FixedMain` iteration runs.
# Objective - bevy usually use `Parallel::scope` to collect items from `par_iter`, but `scope` will be called with every satifified items. it will cause a lot of unnecessary lookup. ## Solution - similar to Rayon ,we introduce `for_each_init` for `par_iter` which only be invoked when spawn a task for a group of items. --- ## Changelog - added `for_each_init` ## Performance `check_visibility ` in `many_foxes `  ~40% performance gain in `check_visibility`. --------- Co-authored-by: James Liu <[email protected]>
# Objective Follow up to bevyengine#13062. As of async-executor 1.11, the crate reexports FallibleTask, which is the only reason bevy_tasks has a direct dependency on async-task. This should avoid the two dependencies getting out of sync in the future and causing spurious compilation failures. ## Solution Bump async-executor to 1.11, use the reexport, remove the dependency on async-task.
# Objective - Be able to edit animation inside the editor and save them once modified. This will allow bevy to modify animation assets with code. - Fixes bevyengine#13052 ## Solution - Expose the previously const getters of the Animation curves ---
# Objective Clarify the comment about the camera's coordinate system in `examples/3d/generate_custom_mesh.rs` by explicitly stating which axes point where. Fixes bevyengine#13018 ## Solution Copy the wording from bevyengine#13012 into the example.
# Objective - GitHub action running iOS CI has been updated to use arm runner - This makes iOS test fail as it's not installing the correct rust target ## Solution - add the correct rust target, do not remove x86 targets for now as it may be some time for a partial rollout
# Objective Both the shedule and winit runners use/reimplement `app_exit_manual` even tough they can use `app_exit` ## Solution Nuke `app_exit_manual` from orbit.
The shader code was removed in bevyengine#11280, but we never cleaned up the rust code.
Adds a basic level of detail system to meshlets. An extremely brief summary is as follows: * In `from_mesh.rs`, once we've built the first level of clusters, we group clusters, simplify the new mega-clusters, and then split the simplified groups back into regular sized clusters. Repeat several times (ideally until you can't anymore). This forms a directed acyclic graph (DAG), where the children are the meshlets from the previous level, and the parents are the more simplified versions of their children. The leaf nodes are meshlets formed from the original mesh. * In `cull_meshlets.wgsl`, each cluster selects whether to render or not based on the LOD bounding sphere (different than the culling bounding sphere) of the current meshlet, the LOD bounding sphere of its parent (the meshlet group from simplification), and the simplification error relative to its children of both the current meshlet and its parent meshlet. This kind of breaks two pass occlusion culling, which will be fixed in a future PR by using an HZB from the previous frame to get the initial list of occluders. Many, _many_ improvements to be done in the future bevyengine#11518, not least of which is code quality and speed. I don't even expect this to work on many types of input meshes. This is just a basic implementation/draft for collaboration. Arguable how much we want to do in this PR, I'll leave that up to maintainers. I've erred on the side of "as basic as possible". References: * Slides 27-77 (video available on youtube) https://advances.realtimerendering.com/s2021/Karis_Nanite_SIGGRAPH_Advances_2021_final.pdf * https://blog.traverseresearch.nl/creating-a-directed-acyclic-graph-from-a-mesh-1329e57286e5 * https://jglrxavpok.github.io/2024/01/19/recreating-nanite-lod-generation.html, https://jglrxavpok.github.io/2024/03/12/recreating-nanite-faster-lod-generation.html, https://jglrxavpok.github.io/2024/04/02/recreating-nanite-runtime-lod-selection.html, and https://github.com/jglrxavpok/Carrot * https://github.com/gents83/INOX/tree/master/crates/plugins/binarizer/src * https://cs418.cs.illinois.edu/website/text/nanite.html   --------- Co-authored-by: Ricky Taylor <[email protected]> Co-authored-by: vero <[email protected]> Co-authored-by: François <[email protected]> Co-authored-by: atlas dostal <[email protected]> Co-authored-by: Patrick Walton <[email protected]>
# Objective - animating a sprite in response to an event is a [common beginner problem](https://www.reddit.com/r/bevy/comments/13xx4v7/sprite_animation_in_bevy/) ## Solution - provide a simple example to show how to animate a sprite in response to an event --------- Co-authored-by: François Mockers <[email protected]>
# Objective - Clippy raises a few warnings on the latest nightly release. 📎 ## Solution - Use `ptr::from_ref` when possible, because it prevents you from accidentally changing the mutability as well as its type. - Use `ptr::addr_eq` when comparing two pointers, ignoring pointer metadata.
# Objective Resolve bevyengine#10054. ## Solution Make dynamic linking a no-op by omitting it from the dependency tree on wasm targets. To test this, try `cargo build --lib --target wasm32-unknown-unknown --features bevy/dynamic_linking` with and without this PR. Might need to update the book on the website to explain this when this makes it into a release. Co-Authored By: @daxpedda --------- Co-authored-by: BD103 <[email protected]>
# Objective - Closes bevyengine#12958 ## Solution - Find all methods under `Query` that mention panicking, and add `#[track_caller]` to them. --- ## Changelog - Added `#[track_caller]` to `Query::many`, `Query::many_mut`, `Query::transmute_lens`, and `Query::transmute_lens_filtered`. ## For reviewers I'm unfamiliar with the depths of the `Query` struct. Please check whether it makes since for the updated methods to have `#[track_caller]`, and if I missed any!
* Maintainers count as community members * The review of the maintainer wanting to merge the PR counts In practice this means that if a maintainer approves a PR, they would no longer need two reviews from _other_ community members, only one.
https://github.com/bevyengine/bevy/assets/2632925/e046205e-3317-47c3-9959-fc94c529f7e0 # Objective - Adds per-object motion blur to the core 3d pipeline. This is a common effect used in games and other simulations. - Partially resolves bevyengine#4710 ## Solution - This is a post-process effect that uses the depth and motion vector buffers to estimate per-object motion blur. The implementation is combined from knowledge from multiple papers and articles. The approach itself, and the shader are quite simple. Most of the effort was in wiring up the bevy rendering plumbing, and properly specializing for HDR and MSAA. - To work with MSAA, the MULTISAMPLED_SHADING wgpu capability is required. I've extracted this code from bevyengine#9000. This is because the prepass buffers are multisampled, and require accessing with `textureLoad` as opposed to the widely compatible `textureSample`. - Added an example to demonstrate the effect of motion blur parameters. ## Future Improvements - While this approach does have limitations, it's one of the most commonly used, and is much better than camera motion blur, which does not consider object velocity. For example, this implementation allows a dolly to track an object, and that object will remain unblurred while the background is blurred. The biggest issue with this implementation is that blur is constrained to the boundaries of objects which results in hard edges. There are solutions to this by either dilating the object or the motion vector buffer, or by taking a different approach such as https://casual-effects.com/research/McGuire2012Blur/index.html - I'm using a noise PRNG function to jitter samples. This could be replaced with a blue noise texture lookup or similar, however after playing with the parameters, it gives quite nice results with 4 samples, and is significantly better than the artifacts generated when not jittering. --- ## Changelog - Added: per-object motion blur. This can be enabled and configured by adding the `MotionBlurBundle` to a camera entity. --------- Co-authored-by: Torstein Grindvik <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Hi! I'm not sure if there's a good way to view how I resolved the merge conflicts, but they are now all fixed.
It still doesn't compile, but that will likely be a later PR.