Fix 3D Gizmo webgpu rendering #14652
Closed
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
…e#13419) Changes: - Track whether an output texture has been written to yet and only clear it on the first write. - Use `ClearColorConfig` on `CameraOutputMode` instead of a raw `LoadOp`. - Track whether a output texture has been seen when specializing the upscaling pipeline and use alpha blending for extra cameras rendering to that texture that do not specify an explicit blend mode. Fixes bevyengine#6754 ## Testing Tested against provided test case in issue:  --- ## Changelog - Allow cameras rendering to the same output texture with mixed hdr to work correctly. ## Migration Guide - - Change `CameraOutputMode` to use `ClearColorConfig` instead of `LoadOp`.
- crate metadata for bevy_state has been copied from bevy_ecs - Update it
# Objective - Document how to release a RC ## Solution - Also allow CI to trigger on release branches
…bevyengine#13732) - Thanks to the original author we can now use the original name - Use it
…engine#13736) # Objective Some use cases might require holding onto the previous state of the animation player for change detection. ## Solution Added `clone` and `copy` implementation to most animation types. Added optimized `clone_from` implementations for the specific use case of holding a `PreviousAnimationPlayer` component. --------- Co-authored-by: Alice Cecile <[email protected]>
Fixes bevyengine#13743. --------- Co-authored-by: Brezak <[email protected]>
# Objective - In bevyengine#13649 additional method had been added to AppExitStates, but there feature gate left for method in implementation for App at refactoring stage. - Fixes bevyengine#13733 . ## Solution - Removed the feature gate. ## Testing - Ran reproducing example from bevyengine#13733 with no compilation errors
) As per the other changes in bevyengine#13489 `view.inverse_clip_from_world` should be `world_from_clip`. # Objective fixes bevyengine#13749 ## Solution Modified lines.wgsl to use the right name as the current name does not exist. ## Testing I ran the 3d_gizmos example and pressed "p".  
# Objective The `EntityCommands::despawn` method was previously changed from panicking behavior to a warning, but the docs continue to state that it panics. ## Solution - Removed panic section, copied warning blurb from `World::despawn` - Adds a similar warning blurb to `DespawnRecursiveExt::despawn_recursive` and `DespawnRecursiveExt::despawn_descendants`
…engine#13779) # Objective - Let `init_non_send_resource` take `FromWorld` values again, not only `Default` - This reverts an unintended breaking change introduced in bevyengine#9202 ## Solution - The resource initialized with `init_non_send_resource` requires `FromWorld` again
# Objective This PR addresses the 2D part of bevyengine#12658. I plan to separate the examples and make one PR per camera example. ## Solution Added a new top-down example composed of: - [x] Player keyboard movements - [x] UI for keyboard instructions - [x] Colors and bloom effect to see the movement of the player - [x] Camera smooth movement towards the player (lerp) ## Testing ```bash cargo run --features="wayland,bevy/dynamic_linking" --example 2d_top_down_camera ``` https://github.com/bevyengine/bevy/assets/10638479/95db0587-e5e0-4f55-be11-97444b795793
# Objective - Add support for `segments` for extrusion-meshes, akin to what is possible with cylinders ## Solution - Added a `.segments(segments: usize)` function to `ExtrusionBuilder`. - Implemented support for segments in the meshing algorithm. - If you set `.segments(0)`, the meshing will fail, just like it does with cylinders. ## Additional information Here is a wireframe of some extrusions with 1, 2, 3, etc. segments:  --------- Co-authored-by: Lynn Büttgenbach <[email protected]>
# Objective The method `AssetServer::add_async` (added in bevyengine#13700) requires a future that returns an `AssetLoadError` error, which was a bit of an oversight on my part, as that type of error only really makes sense in the context of bevy's own asset loader -- returning it from user-defined futures isn't very useful. ## Solution Allow passing custom error types to `add_async`, which get cast into a trait object matching the form of `AssetLoader::load`. If merged before the next release this will not be a breaking change
…e#13752) Mip bias is no longer used here
…o RGB color types, also renames Color::linear to Color::to_linear. (bevyengine#13759) # Objective One thing missing from the new Color implementation in 0.14 is the ability to easily convert to a u8 representation of the rgb color. (note this is a redo of PR bevyengine#13739 as I needed to move the source branch ## Solution I have added to_u8_array and to_u8_array_no_alpha to a new trait called ColorToPacked to mirror the f32 conversions in ColorToComponents and implemented the new trait for Srgba and LinearRgba. To go with those I also added matching from_u8... functions and converted a couple of cases that used ad-hoc implementations of that conversion to use these. After discussion on Discord of the experience of using the API I renamed Color::linear to Color::to_linear, as without that it looks like a constructor (like Color::rgb). I also added to_srgba which is the other commonly converted to type of color (for UI and 2D) to match to_linear. Removed a redundant extra implementation of to_f32_array for LinearColor as it is also supplied in ColorToComponents (I'm surprised that's allowed?) ## Testing Ran all tests and manually tested. Added to_and_from_u8 to linear_rgba::tests ## Changelog visible change is Color::linear becomes Color::to_linear. --------- Co-authored-by: John Payne <[email protected]>
- Copy module docs so that they show up in the re-export - Change meshlet_id to cluster_id in the debug visualization - Small doc tweaks
…evyengine#13763) # Objective Fixes bevyengine#13711 ## Solution Introduce smaller, generic system sets for each schedule variant, which are ordered against other generic variants: - `ExitSchedules<S>` - For `OnExit` schedules, runs from leaf states to root states. - `TransitionSchedules<S>` - For `OnTransition` schedules, runs in arbitrary order. - `EnterSchedules<S>` - For `OnEnter` schedules, runs from root states to leaf states. Also unified `ApplyStateTransition<S>` schedule which works in basically the same way, just for internals. ## Testing - One test that tests schedule execution order --------- Co-authored-by: Lee-Orr <[email protected]>
# Objective The error printed-out due to a missing shader file was confusing; This PR changes the error message. Fixes bevyengine#13644 ## Solution I replaced the confusing wording (`... shader is not loaded yet`) with a clear explanation (`... shader could not be loaded`) ## Testing > Did you test these changes? If so, how? removing `assets/shaders/game_of_life.wgsl` & running its associated example now produces the following error: ``` thread '<unnamed>' panicked at examples/shader/compute_shader_game_of_life.rs:233:25: Initializing assets/shaders/game_of_life.wgsl: Pipeline could not be compiled because the following shader could not be loaded: AssetId<bevy_render::render_resource::shader::Shader>{ index: 0, generation: 0} note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace Encountered a panic in system `bevy_render::renderer::render_system`! ``` I don't think there are any tests expecting the previous error message, so this change should not break anything. > Are there any parts that need more testing? If there was an intent behind the original message, this might need more attention. > How can other people (reviewers) test your changes? Is there anything specific they need to know? One should be able to preview the changes by running any example after deleting/renaming their associated shader(s). > If relevant, what platforms did you test these changes on, and are there any important ones you can't test? N/A
bevyengine#13772) The documentation for the `State` resource still referenced the use of `apply_state_transition` to manually force a state transition to occur, and the question around how to force transitions had come up a few times on discord. This is a docs-only change, that does the following: - Properly references `StateTransition` in the `MainSchedule` docs - replace the explanations for applying `NextState` with ones that explain the `StateTransition` schedule, and mentions the possibility of calling it manually - Add an example of calling `StateTransition` manually in the docs for the state transition schedule itself. --------- Co-authored-by: Alice Cecile <[email protected]>
) # Objective - If the fog is disabled it still generates a useless branch which can hurt performance ## Solution - Make the flag a shader_def instead ## Testing - I tested enabling/disabling fog works as expected per-material in the fog example - I also tested that scenes that don't add the FogSettings resource still work correctly ## Review notes I'm not sure how to handle the removed material flag. Right now I just commented it out and added a not to reuse it instead of creating a new one.
# Objective There were some issues with the `serialize` feature: - `bevy_app` had a `serialize` feature and a dependency on `serde` even there is no usage of serde at all inside `bevy_app` - the `bevy_app/serialize` feature enabled `bevy_ecs/serde`, which is strange - `bevy_internal/serialize` did not enable `bevy_app/serialize` so there was no way of serializing an Entity in bevy 0.14 ## Solution - Remove `serde` and `bevy_app/serialize` - Add a `serialize` flag on `bevy_ecs` that enables `serde` - ` bevy_internal/serialize` now enables `bevy_ecs/serialize`
Fixes bevyengine#13758. # Objective Calling `update` on the main app already calls `clear_trackers`. Calling it again in `SubApps::update` caused RemovedCompenet Events to be cleared earlier than they should be. ## Solution - Don't call clear_trackers an extra time. ## Testing I manually tested the fix with this unit test: ``` #[cfg(test)] mod test { use crate::core::{FrameCount, FrameCountPlugin}; use crate::prelude::*; #[test] fn test_next_frame_removal() { #[derive(Component)] struct Foo; #[derive(Resource)] struct RemovedCount(usize); let mut app = App::new(); app.add_plugins(FrameCountPlugin); app.add_systems(Startup, |mut commands: Commands| { for _ in 0..100 { commands.spawn(Foo); } commands.insert_resource(RemovedCount(0)); }); app.add_systems(First, |counter: Res<FrameCount>| { println!("Frame {}:", counter.0) }); fn detector_system( mut removals: RemovedComponents<Foo>, foos: Query<Entity, With<Foo>>, mut removed_c: ResMut<RemovedCount>, ) { for e in removals.read() { println!(" Detected removed Foo component for {e:?}"); removed_c.0 += 1; } let c = foos.iter().count(); println!(" Total Foos: {}", c); assert_eq!(c + removed_c.0, 100); } fn deleter_system(foos: Query<Entity, With<Foo>>, mut commands: Commands) { foos.iter().next().map(|e| { commands.entity(e).remove::<Foo>(); }); } app.add_systems(Update, (detector_system, deleter_system).chain()); app.update(); app.update(); app.update(); app.update(); } } ```
Reading system information severely slows down the update loop. Fixes bevyengine#12848. Read system info in a separate thread. - Open the scene 3d example - Add `FrameTimeDiagnosticsPlugin`, `SystemInformationDiagnosticsPlugin` and `LogDiagnosticsPlugin` to the app. - Add this system to the update schedule to disable Vsync on the main window ```rust fn change_window_mode(mut windows: Query<&mut Window, Added<Window>>) { for mut window in &mut windows { window.present_mode = PresentMode::AutoNoVsync; } } ``` - Read the fps values in the console before and after this PR. On my PC I went from around 50 fps to around 1150 fps. --- - The `SystemInformationDiagnosticsPlugin` now reads system data separate of the update cycle. - The `EXPECTED_SYSTEM_INFORMATION_INTERVAL` constant which defines how often we read system diagnostic data. --------- Co-authored-by: IceSentry <[email protected]>
# Objective - Mikktspace requires that we normalize world normals/tangents _before_ interpolation across vertices, and then do _not_ normalize after. I had it backwards. - We do not (am not supposed to?) need a second set of barycentrics for motion vectors. If you think about the typical raster pipeline, in the vertex shader we calculate previous_world_position, and then it gets interpolated using the current triangle's barycentrics. ## Solution - Fix normal/tangent processing - Reuse barycentrics for motion vector calculations - Not implementing this for 0.14, but long term I aim to remove explicit vertex tangents and calculate them in the shader on the fly. ## Testing - I tested out some of the normal maps we have in repo. Didn't seem to make a difference, but mikktspace is all about correctness across various baking tools. I probably just didn't have any of the ones that would cause it to break. - Didn't test motion vectors as there's a known bug with the depth buffer and meshlets that I'm waiting on the render graph rewrite to fix.
# Objective - Add a new example showcasing how to add custom primitives and what you can do with them. ## Solution - Added a new example `custom_primitives` with a 2D heart shape primitive highlighting - `Bounded2d` by implementing and visualising bounding shapes, - `Measured2d` by implementing it, - `Meshable` to show the shape on the screen - The example also includes an `Extrusion<Heart>` implementing - `Measured3d`, - `Bounded3d` using the `BoundedExtrusion` trait and - meshing using the `Extrudable` trait. ## Additional information Here are two images of the heart and its extrusion:   --------- Co-authored-by: Jakub Marcowski <[email protected]>
…e#13791) # Objective Closes bevyengine#13738 ## Solution Added `from_color` to materials that would support it. Didn't add `from_color` to `WireframeMaterial` as it doesn't seem we expect users to be constructing them themselves. ## Testing None --- ## Changelog ### Added - `from_color` to `StandardMaterial` so you can construct this material from any color type. - `from_color` to `ColorMaterial` so you can construct this material from any color type.
…ngine#13783)" (bevyengine#13803) This reverts commit 3ced49f. Relevant to bevyengine#13802. This wasn't done quite right and partially broke fog. Co-authored-by: Alice Cecile <[email protected]>
# Objective Fixes bevyengine#14301 ## Solution Swap them so that they are no longer swapped.
Fixes bevyengine#14157 - Update the ObserverSystem traits to accept an `Out` parameter - Added a test where an observer system has a non-empty output which is piped into another system Co-authored-by: Alice Cecile <[email protected]>
) # Objective - Fixes bevyengine#14206 ## Solution - Run initial `StateTransition` as a startup schedule before `PreStartup`, instead of running it inside `Startup` as an exclusive system. Related discord discussion: https://discord.com/channels/691052431525675048/692572690833473578/1259543775668207678 ## Testing Reproduction now works correctly: ```rs use bevy::prelude::*; #[derive(Debug, Clone, Copy, Default, Eq, PartialEq, Hash, States)] enum AppState { #[default] Menu, InGame, } fn main() { App::new() .add_plugins(DefaultPlugins) .init_state::<AppState>() .add_systems(Startup, setup) .add_systems(OnEnter(AppState::Menu), enter_menu_state) .run(); } fn setup(mut next_state: ResMut<NextState<AppState>>) { next_state.set(AppState::Menu); } fn enter_menu_state() { println!("Entered menu state"); } ```  --- ## Changelog - Initial `StateTransition` runs before `PreStartup` instead of inside `Startup`.
# Objective - Fixes overflow when calling `RenderLayers::iter_layers` on layers of the form `k * 64 - 1` - Causes a panic in debug mode, and an infinite iterator in release mode ## Solution - Use `u64::checked_shr` instead of `>>=` ## Testing - Added a test case for this: `render_layer_iter_no_overflow`
# Objective - [`flag-frenzy`](https://github.com/TheBevyFlock/flag-frenzy) found an issue where `bevy_window` would fail to build when its `serialize` feature is enabled. - See [here](https://github.com/TheBevyFlock/flag-frenzy/actions/runs/9924187577/job/27415224405) for the specific log. ## Solution - Turns out it was failing because the `bevy_ecs/serialize` feature was not enabled. This error can be fixed by adding the flag as a dependency. ## Testing ```bash cargo check -p bevy_window -F serialize # Or if you're very cool... flag-frenzy --manifest-path path/to/bevy/Cargo.toml --config config -p bevy_window ```
# Objective - Actually use the value assigned to `d_xz`, like in [the original SMAA implementation](https://github.com/iryoku/smaa/blob/master/SMAA.hlsl#L960). This not already being the case was likely a mistake when converting from HLSL to WGSL ## Solution - Use `d_xz.x` and `d_xz.y` instead of `d.x` and `d.z` ## Testing - Quickly tested on Windows 11, `x86_64-pc-windows-gnu` `1.79.0` with the latest NVIDIA drivers. App runs with SMAA enabled and everything seems to work as intended - I didn't observe any major visual difference between this and the previous version, though this should be more correct as it matches the original SMAA implementation
# Objective - The current default viewport crashes bevy due to a wgpu validation error, this PR fixes that - Fixes bevyengine#14355 ## Solution - `Viewport::default()` now returns a 1x1 viewport ## Testing - I modified the `3d_viewport_to_world` example to use `Viewport::default()`, and it works as expected (only the top-left pixel is rendered)
# Objective
- Building bevy_gltf with feature dds fails:
```
> cargo build -p bevy_gltf --features dds
Compiling bevy_core_pipeline v0.15.0-dev (crates/bevy_core_pipeline)
error[E0061]: this function takes 7 arguments but 6 arguments were supplied
--> crates/bevy_core_pipeline/src/tonemapping/mod.rs:442:5
|
442 | Image::from_buffer(
| ^^^^^^^^^^^^^^^^^^
...
445 | bytes,
| ----- an argument of type `std::string::String` is missing
|
note: associated function defined here
--> crates/bevy_render/src/texture/image.rs:709:12
|
709 | pub fn from_buffer(
| ^^^^^^^^^^^
help: provide the argument
|
442 | Image::from_buffer(/* std::string::String */, bytes, image_type, CompressedImageFormats::NONE, false, image_sampler, RenderAssetUsages::RENDER_WORLD)
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For more information about this error, try `rustc --explain E0061`.
error: could not compile `bevy_core_pipeline` (lib) due to 1 previous error
```
- If you're fixing a specific issue, say "Fixes #X".
## Solution
- enable dds feature in bevy_core_pipeline
## Testing
- `cargo build -p bevy_gltf --features dds`
…yengine#14260) # Objective - Fixes bevyengine#14139 ## Solution - correct the input parameters at these call sites. ## Testing 1. Use a 3D scene example with PBR lighting and shadows enabled, such as the `shadow_caster_receiver` and `load_gltf` example, for testing. 2. Enable relevant shader defines in crates/bevy_pbr/src/pbr_material.rs for the StandardMaterial. ```rust impl Material for StandardMaterial { // ... fn specialize( _pipeline: &MaterialPipeline<Self>, descriptor: &mut RenderPipelineDescriptor, _layout: &MeshVertexBufferLayoutRef, key: MaterialPipelineKey<Self>, ) -> Result<(), SpecializedMeshPipelineError> { // ... // shader_defs.push("CLUSTERED_FORWARD_DEBUG_Z_SLICES".into()); // shader_defs.push("CLUSTERED_FORWARD_DEBUG_CLUSTER_COHERENCY".into()); shader_defs.push("DIRECTIONAL_LIGHT_SHADOW_MAP_DEBUG_CASCADES".into()); // ... } } ``` ## Showcase ### CLUSTERED_FORWARD_DEBUG_Z_SLICES - example: examples/3d/shadow_caster_receiver.rs  ### CLUSTERED_FORWARD_DEBUG_CLUSTER_COHERENCY - example: examples/3d/shadow_caster_receiver.rs  ### DIRECTIONAL_LIGHT_SHADOW_MAP_DEBUG_CASCADES For this one, we need to use a large scene and modity the `CascadeShadowConfigBuilder`, here is a simple patch for the `load_gltf` example: ``` diff --git a/examples/3d/load_gltf.rs b/examples/3d/load_gltf.rs index 358446238..9403aa288 100644 --- a/examples/3d/load_gltf.rs +++ b/examples/3d/load_gltf.rs @@ -18,7 +18,7 @@ fn main() { fn setup(mut commands: Commands, asset_server: Res<AssetServer>) { commands.spawn(( Camera3dBundle { - transform: Transform::from_xyz(0.7, 0.7, 1.0) + transform: Transform::from_xyz(0.7, 0.7, 2.0) .looking_at(Vec3::new(0.0, 0.3, 0.0), Vec3::Y), ..default() }, @@ -39,30 +39,40 @@ fn setup(mut commands: Commands, asset_server: Res<AssetServer>) { // We also adjusted the shadow map to be larger since we're // only using a single cascade. cascade_shadow_config: CascadeShadowConfigBuilder { - num_cascades: 1, - maximum_distance: 1.6, + num_cascades: 5, + maximum_distance: 20.0, ..default() } .into(), ..default() }); + commands.spawn(SceneBundle { scene: asset_server .load(GltfAssetLabel::Scene(0).from_asset("models/FlightHelmet/FlightHelmet.gltf")), ..default() }); + + for i in 1..=10 { + commands.spawn(SceneBundle { + scene: asset_server + .load(GltfAssetLabel::Scene(0).from_asset("models/FlightHelmet/FlightHelmet.gltf")), + transform: Transform::from_xyz(i as f32 * 0.5, 0.0, i as f32 * -2.0), + ..default() + }); + } } fn animate_light_direction( time: Res<Time>, mut query: Query<&mut Transform, With<DirectionalLight>>, ) { - for mut transform in &mut query { - transform.rotation = Quat::from_euler( - EulerRot::ZYX, - 0.0, - time.elapsed_seconds() * PI / 5.0, - -FRAC_PI_4, - ); - } + // for mut transform in &mut query { + // transform.rotation = Quat::from_euler( + // EulerRot::ZYX, + // 0.0, + // time.elapsed_seconds() * PI / 5.0, + // -FRAC_PI_4, + // ); + // } } ```  --------- Co-authored-by: ickshonpe <[email protected]>
# Objective
- Some types are missing reflection attributes, which means we can't use
them in scene serialization etc.
- Effected types
- `BorderRadius`
- `AnimationTransitions`
- `OnAdd`
- `OnInsert`
- `OnRemove`
- My use-case for `OnAdd` etc to derive reflect is 'Serializable
Observer Components'. Add the component, save the scene, then the
observer is re-added on scene load.
```rust
#[derive(Reflect)]
struct MySerializeableObserver<T: Event>(#[reflect(ignore)]PhantomData<T>);
impl<T: Event> Component for MySerializeableObserver<T> {
const STORAGE_TYPE: StorageType = StorageType::Table;
fn register_component_hooks(hooks: &mut ComponentHooks) {
hooks.on_add(|mut world, entity, _| {
world
.commands()
.entity(entity)
.observe(|_trigger: Trigger<T>| {
println!("it triggered etc.");
});
});
}
}
```
## Solution
- Add the missing traits
---
# Objective For clips with more than one curve, only the first was being applied if there is only one keyframe in it. ## Solution Continue!
…ags (bevyengine#14486) # Objective - `bevy_gltf` does not build with only the `pbr_multi_layer_material_textures` or `pbr_anisotropy_texture` features. - Caught by [`flag-frenzy`](https://github.com/TheBevyFlock/flag-frenzy) in [this run](https://github.com/TheBevyFlock/flag-frenzy/actions/runs/10087486444/job/27891723948). ## Solution - This error was due to the feature not enabling the corresponding feature in `bevy_pbr`. Adding these flags as a dependency fixes this error. ## Testing The following commands fail on `main`, but pass with this PR: ```bash cargo check -p bevy_gltf --no-default-features -F pbr_multi_layer_material_textures cargo check -p bevy_gltf --no-default-features -F pbr_anisotropy_texture ```
# Objective - Fix a confusing panic when the viewport width is non-zero and the height is 0, `prepare_bloom_textures` tries to create a `4294967295x1` texture. ## Solution - Avoid dividing by zero - Apps still crash after this, but now on a more reasonable error about the zero-size viewport ## Testing - I isolated and tested the math. A height of 0 sets `mip_height_ratio` to `inf`, causing the width to explode if it isn't also 0
) # Objective - `bevy_winit` fails to build with just the `serialize` feature. - Caught by [`flag-frenzy`](https://github.com/TheBevyFlock/flag-frenzy) in [this run](https://github.com/TheBevyFlock/flag-frenzy/actions/runs/10087486444/job/27891723948), using the new, nuanced configuration system! ## Solution - It was failing because `bevy_winit` did not pass the `serialize` flag to two of its dependencies: `bevy_input` and `bevy_window`. - To fix this, add these crates to the feature flag. ## Testing ```bash # On Linux, you must also specify a backend: `x11` or `wayland`. # You can do this with `-F serialize,x11`, etc. cargo check -p bevy_winit --no-default-features -F serialize ```
) # Objective Fix a memory leak in `TextureCache` caused by the internal HashMap never having unused entries cleared. This isn't a giant memory leak, given the unused entries are simply empty vectors. Though, if someone goes and resizes a window a bunch, it can lead to hundreds/thousands of TextureDescriptor keys adding up in the hashmap – which isn't ideal. ## Solution - Only retain hashmap entries that still have textures. - I also added an `is_empty()` method to `TextureCache`, which is useful for 3rd-party higher-level caches that might have individual caches by view entity or texture type, for example. ## Testing - Verified the examples still work (this is a trivial change)
# Objective - `bevy_render` depends on `image 0.25` but uses `image::ImageReader` which was added only in `image 0.25.2` - users that have `image 0.25` in their `Cargo.lock` and update to the latest `bevy_render` may thus get a compilation due to this (at least I did) ## Solution - Properly set the correct minimum version of `image` that `bevy_render` depends on.
…evyengine#14402) Fixes bevyengine#14353 Fixes bevyengine#14371 --------- Signed-off-by: Sarthak Singh <[email protected]> Co-authored-by: Alice Cecile <[email protected]> Co-authored-by: BD103 <[email protected]>
# Objective The `ui_layout_system` relies on change detection to sync parent-child relation to taffy. The children need to by synced before node removal to avoid trying to set deleted nodes as children (due to how the different queries collect entities). This however may leave nodes that were removed set as children to other nodes in special cases. Fixes bevyengine#11385 ## Solution The solution is simply to re-sync the changed children after the nodes are removed. ## Testing Tested with `sickle_ui` where docking zone highlights would end up glitched when docking was done in a certain manner: - run the `docking_zone_splits` example - pop out a tab from the top - dock the floating panel in the center right - grab another tab and try to hover the original static docking zone: the highlight is semi-stuck - (NOTE: sometimes it worked even without the fix due to scheduling order not producing the bugged query results) After the fix, the issue is no longer present. NOTE: The performance impact should be minimal, as the child sync relies on change detection. The change detection was also the reason the parent nodes remained "stuck" with the phantom children if no other update were done to them.
# Objective Spamming the window close button on window may trigger a panic. ``` thread 'main' panicked at <Bevy repo>\crates\bevy_ecs\src\system\commands\mod.rs:1320:13: error[B0003]: Could not insert a bundle (of type `bevy_window::window::ClosingWindow`) for entity 0v1#4294967296 because it doesn't exist in this World. See: https://bevyengine.org/learn/errors/b0003 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace Encountered a panic when applying buffers for system `bevy_window::system::close_when_requested`! 2024-08-01T15:00:29.742612Z WARN bevy_ecs::world::command_queue: CommandQueue has un-applied commands being dropped. Did you forget to call SystemState::apply? Encountered a panic in system `bevy_app::main_schedule::Main::run_main`! error: process didn't exit successfully: `target\debug\bevy.exe` (exit code: 101) ``` ## Solution Don't panic when trying to insert the `ClosingWindow` component into a entity. ## Testing Found and tested on windows. I haven't checked if this bug happens on linux or macos. For testing I ran this code: ```rust use std::{thread, time::Duration}; use bevy::prelude::*; fn lag() { thread::sleep(Duration::from_millis(300)); } fn main() -> AppExit { App::new() .add_plugins(DefaultPlugins) .add_systems(Update, lag) .run() } ``` Then spammed the window close button. The panic no longer occurs.
# Objective Fixes bevyengine#14147. ## Solution Modify the slicing checks and algorithm to fully allow asymmetrical textures to work. Some opinionated code cleanup. ## Testing Tested using the ui_texture_slice example and a custom asymmetrical texture. Before:  After:  --------- Co-authored-by: Alice Cecile <[email protected]>
# Objective - Fix bevyengine#14295 ## Solution - Early out when `GFBD::get_index_and_compare_data` returns None. ## Testing - Tested on a selection of examples including `many_foxes` and `3d_shapes`. - Resolved the original issue in `bevy_vector_shapes`.
# Objective Fixes bevyengine#13866 ## Solution Add `insert_before` in **FixedMainScheduleOrder** and **MainScheduleOrder**, add `insert_startup_before` in **MainScheduleOrder**, applying the same logic as `insert_after`, except for parameters naming and insertion index.
|
Welcome, new contributor! Please make sure you've read our contributing guide and we look forward to reviewing your pull request shortly ✨ |
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.
Objective
The changes made in #12252 introduced an previously fixed bug in webgpu rendering.
Solution
This fix is based on #8910 and applies the same vertex buffer layout assignment for the LineGizmo Pipeline.
Testing