40b05b2116
6 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
Wybe Westra
|
55c84cc722
|
Added HeadlessPlugins (#15203) (#15260)
Added a `HeadlessPlugins` plugin group, that adds more default functionality (like logging) than the `MinimumPlugins`. Fixes #15203 Changed the headless example to use the new plugin group. I am not entirely sure if the list of plugins is correct. Are there ones that should be added / removed? ---- The `TerminalCtrlCHandlerPlugin` has interesting effects in the headless example: Installing it a second time it will give a log message about skipping installation, because it is already installed. Ctrl+C will terminate the application in that case. However, _not_ installing it the second time (so only on the app that runs once) has the effect that the app that runs continuously cannot be stopped using Ctrl+C. This implies that, even though the second app did not install the Ctrl+C handler, it did _something_ because it was keeping the one from the first app alive. Not sure if this is a problem or issue, or can be labeled a wierd quirk of having multiple Apps in one executable. |
||
|
Alice Cecile
|
4ac2a63556
|
Remove all existing system order ambiguities in DefaultPlugins (#15031)
# Objective As discussed in https://github.com/bevyengine/bevy/issues/7386, system order ambiguities within `DefaultPlugins` are a source of bugs in the engine and badly pollute diagnostic output for users. We should eliminate them! This PR is an alternative to #15027: with all external ambiguities silenced, this should be much less prone to merge conflicts and the test output should be much easier for authors to understand. Note that system order ambiguities are still permitted in the `RenderApp`: these need a bit of thought in terms of how to test them, and will be fairly involved to fix. While these aren't *good*, they'll generally only cause graphical bugs, not logic ones. ## Solution All remaining system order ambiguities have been resolved. Review this PR commit-by-commit to see how each of these problems were fixed. ## Testing `cargo run --example ambiguity_detection` passes with no panics or logging! |
||
|
charlotte
|
d9527c101c
|
Rewrite screenshots. (#14833)
# Objective Rewrite screenshotting to be able to accept any `RenderTarget`. Closes #12478 ## Solution Previously, screenshotting relied on setting a variety of state on the requested window. When extracted, the window's `swap_chain_texture_view` property would be swapped out with a texture_view created that frame for the screenshot pipeline to write back to the cpu. Besides being tightly coupled to window in a way that prevented screenshotting other render targets, this approach had the drawback of relying on the implicit state of `swap_chain_texture_view` being returned from a `NormalizedRenderTarget` when view targets were prepared. Because property is set every frame for windows, that wasn't a problem, but poses a problem for render target images. Namely, to do the equivalent trick, we'd have to replace the `GpuImage`'s texture view, and somehow restore it later. As such, this PR creates a new `prepare_view_textures` system which runs before `prepare_view_targets` that allows a new `prepare_screenshots` system to be sandwiched between and overwrite the render targets texture view if a screenshot has been requested that frame for the given target. Additionally, screenshotting itself has been changed to use a component + observer pattern. We now spawn a `Screenshot` component into the world, whose lifetime is tracked with a series of marker components. When the screenshot is read back to the CPU, we send the image over a channel back to the main world where an observer fires on the screenshot entity before being despawned the next frame. This allows the user to access resources in their save callback that might be useful (e.g. uploading the screenshot over the network, etc.). ## Testing  TODO: - [x] Web - [ ] Manual texture view --- ## Showcase render to texture example: <img src="https://github.com/user-attachments/assets/612ac47b-8a24-4287-a745-3051837963b0" width=200/> web saving still works: <img src="https://github.com/user-attachments/assets/e2a15b17-1ff5-4006-ab2a-e5cc74888b9c" width=200/> ## Migration Guide `ScreenshotManager` has been removed. To take a screenshot, spawn a `Screenshot` entity with the specified render target and provide an observer targeting the `ScreenshotCaptured` event. See the `window/screenshot` example to see an example. --------- Co-authored-by: Kristoffer Søholm <k.soeholm@gmail.com> |
||
|
Thierry Berger
|
26fc4c7198
|
Test for ambiguous system ordering in CI (#13950)
Progress towards https://github.com/bevyengine/bevy/issues/7386. Following discussion https://discord.com/channels/691052431525675048/1253260494538539048/1253387942311886960 This Pull Request adds an example to detect system order ambiguities, and also asserts none exist. A lot of schedules are ignored in ordered to have the test passing, we should thrive to make them pass, but in other pull requests. <details><summary>example output <b>summary</b>, without ignored schedules</summary> <p> ```txt $ cargo run --example ambiguity_detection 2>&1 | grep -C 1 "pairs of syst" 2024-06-21T13:17:55.776585Z WARN bevy_ecs::schedule::schedule: Schedule First has ambiguities. 1 pairs of systems with conflicting data access have indeterminate execution order. Consider adding `before`, `after`, or `ambiguous_with` relationships between these: -- bevy_time::time_system (in set TimeSystem) and bevy_ecs::event::event_update_system (in set EventUpdates) -- 2024-06-21T13:17:55.782265Z WARN bevy_ecs::schedule::schedule: Schedule PreUpdate has ambiguities. 11 pairs of systems with conflicting data access have indeterminate execution order. Consider adding `before`, `after`, or `ambiguous_with` relationships between these: -- bevy_pbr::prepass::update_mesh_previous_global_transforms and bevy_asset::server::handle_internal_asset_events -- 2024-06-21T13:17:55.809516Z WARN bevy_ecs::schedule::schedule: Schedule PostUpdate has ambiguities. 63 pairs of systems with conflicting data access have indeterminate execution order. Consider adding `before`, `after`, or `ambiguous_with` relationships between these: -- bevy_ui::accessibility::image_changed and bevy_ecs::schedule::executor::apply_deferred -- 2024-06-21T13:17:55.816287Z WARN bevy_ecs::schedule::schedule: Schedule Last has ambiguities. 3 pairs of systems with conflicting data access have indeterminate execution order. Consider adding `before`, `after`, or `ambiguous_with` relationships between these: -- bevy_gizmos::update_gizmo_meshes<bevy_gizmos::aabb::AabbGizmoConfigGroup> (in set UpdateGizmoMeshes) and bevy_gizmos::update_gizmo_meshes<bevy_gizmos::light::LightGizmoConfigGroup> (in set UpdateGizmoMeshes) -- 2024-06-21T13:17:55.831074Z WARN bevy_ecs::schedule::schedule: Schedule ExtractSchedule has ambiguities. 296 pairs of systems with conflicting data access have indeterminate execution order. Consider adding `before`, `after`, or `ambiguous_with` relationships between these: -- bevy_render::extract_component::extract_components<bevy_sprite::SpriteSource> and bevy_render::render_asset::extract_render_asset<bevy_sprite::mesh2d::material::PreparedMaterial2d<bevy_sprite::mesh2d::color_material::ColorMaterial>> ``` </p> </details> To try locally: ```sh CI_TESTING_CONFIG="./.github/example-run/ambiguity_detection.ron" cargo run --example ambiguity_detection --features "bevy_ci_testing,trace,trace_chrome" ``` --------- Co-authored-by: Jan Hohenheim <jan@hohenheim.ch> |
||
|
BD103
|
c3057d4353
|
plugin_group! macro (adopted) (#14339)
# Objective - Adopted from #11460. - Closes #7332. - The documentation for `DefaultPlugins` and `MinimalPlugins` frequently goes out of date because it is not . ## Solution - Create a macro, `plugin_group!`, to automatically create `PluginGroup`s and document them. ## Testing - Run `cargo-expand` on the generated code for `DefaultPlugins` and `MinimalPlugins`. - Try creating a custom plugin group with the macro. --- ## Showcase - You can now define custom `PluginGroup`s using the `plugin_group!` macro. ```rust plugin_group! { /// My really cool plugic group! pub struct MyPluginGroup { physics:::PhysicsPlugin, rendering:::RenderingPlugin, ui:::UiPlugin, } } ``` <details> <summary>Expanded output</summary> ```rust /// My really cool plugic group! /// /// - [`PhysicsPlugin`](physics::PhysicsPlugin) /// - [`RenderingPlugin`](rendering::RenderingPlugin) /// - [`UiPlugin`](ui::UiPlugin) pub struct MyPluginGroup; impl ::bevy_app::PluginGroup for MyPluginGroup { fn build(self) -> ::bevy_app::PluginGroupBuilder { let mut group = ::bevy_app::PluginGroupBuilder::start::<Self>(); { const _: () = { const fn check_default<T: Default>() {} check_default::<physics::PhysicsPlugin>(); }; group = group.add(<physics::PhysicsPlugin>::default()); } { const _: () = { const fn check_default<T: Default>() {} check_default::<rendering::RenderingPlugin>(); }; group = group.add(<rendering::RenderingPlugin>::default()); } { const _: () = { const fn check_default<T: Default>() {} check_default::<ui::UiPlugin>(); }; group = group.add(<ui::UiPlugin>::default()); } group } } ``` </details> --------- Co-authored-by: Doonv <58695417+doonv@users.noreply.github.com> Co-authored-by: Mateusz Wachowiak <mateusz_wachowiak@outlook.com> |
||
|
BD103
|
b0409f63d5
|
Refactor ci_testing and separate it from DevToolsPlugin (#13513)
# Objective - We use [`ci_testing`](https://dev-docs.bevyengine.org/bevy/dev_tools/ci_testing/index.html) to specify per-example configuration on when to take a screenshot, when to exit, etc. - In the future more features may be added, such as #13512. To support this growth, `ci_testing` should be easier to read and maintain. ## Solution - Convert `ci_testing.rs` into the folder `ci_testing`, splitting the configuration and systems into `ci_testing/config.rs` and `ci_testing/systems.rs`. - Convert `setup_app` into the plugin `CiTestingPlugin`. This new plugin is added to both `DefaultPlugins` and `MinimalPlugins`. - Remove `DevToolsPlugin` from `MinimalPlugins`, since it was only used for CI testing. - Clean up some code, add many comments, and add a few unit tests. ## Testing The most important part is that this still passes all of the CI validation checks (merge queue), since that is when it will be used the most. I don't think I changed any behavior, so it should operate the same. You can also test it locally using: ```shell # Run the breakout example, enabling `bevy_ci_testing` and loading the configuration used in CI. CI_TESTING_CONFIG=".github/example-run/breakout.ron" cargo r --example breakout -F bevy_ci_testing ``` --- ## Changelog - Added `CiTestingPlugin`, which is split off from `DevToolsPlugin`. - Removed `DevToolsPlugin` from `MinimalPlugins`. ## Migration Guide Hi maintainers! I believe `DevToolsPlugin` was added within the same release as this PR, so I don't think a migration guide is needed. `DevToolsPlugin` is no longer included in `MinimalPlugins`, so you will need to remove it manually. ```rust // Before App::new() .add_plugins(MinimalPlugins) .run(); // After App::new() .add_plugins(MinimalPlugins) .add_plugins(DevToolsPlugin) .run(); ``` --------- Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com> Co-authored-by: François Mockers <francois.mockers@vleue.com> |