# Objective
- Fixes#19742
## Solution
- Initially I made it an optional feature on bevy_core_widgets and piped
it through to bevy_internal, but then I realized that its not actually
directly reference in the crate so its safe to just remove it.
# Objective
- Add a release note for the new zstd backend.
- Doing so, I realized it was really cumbersome to enable this feature
because we default-enable ruzstd AND make it take precedence if both are
enabled. We can improve ux a bit by making the optional feature take
precedence when both are enabled. This still doesnt remove the unneeded
dependency, but oh well.
Note: it would be nice to have a way to make zstd_c not do anything when
building wasm, but im not sure theres a way to do that, as it seems like
it would need negative features.
---------
Co-authored-by: Jan Hohenheim <jan@hohenheim.ch>
# Objective
- Fix#20014
## Solution
- Don't make the `force_register_` family of functions always enqueue of
the component/resource; instead have them check again whether it was
already queued or not.
## Testing
- I added a small regression test but it's non-deterministic: if the bug
is fixed it will always pass, but if the bug is presen then it has a
(hopefully small) chance of passing. On my PC it failed after ~100
iterations, so hopefully 1000 is enough in CI (assuming it doesn't have
single core runners...)
---------
Co-authored-by: JaySpruce <jsprucebruce@gmail.com>
# Objective
- Progress towards #19887.
## Solution
- For cases that don't need to conditionally add systems, we can just
replace FromWorld impls with systems and then add those systems to
`RenderStartup`.
## Testing
- I ran the `lightmaps`, `reflection_probes`, `deferred_rendering`,
`volumetric_fog`, and `wireframe` examples.
# Objective
Follow on fixes for #19876, using `active_types` instead of
`active_fields` where appropriate.
Helps a tiny bit with #19873.
## Solution
- Describe the solution used to achieve the objective above.
## Testing
I checked the output of `cargo expand` and ran `cargo run -p ci`.
## Solution
While poking around `NestedLoader` I noticed that one code path fails to
pass on the loader's meta transform.
```diff
- .get_or_create_path_handle(path, None)
+ .get_or_create_path_handle(path, self.meta_transform)
```
This seems like a simple oversight - all other code paths pass on the
meta transform where possible - although I'm not familiar enough with
the asset system to be 100% sure. It was introduced when asset loaders
were changed to use the builder pattern (#13465).
Unfortunately I couldn't find an example that actually hits this code
path. So I don't have a good test case, and I don't know if any users
have experienced it as a bug.
## Testing
```
cargo test -p bevy_asset
```
Also tested various examples - `testbed_2d`, `testbed_3d` and everything
in `examples/asset`.
# Objective
Fix a crash when minimizing a window. (#16704) It happens when the
window contains Camera with a custom Viewport.
## Solution
Remove ExtractedCamera when the corresponding camera in main world has
zero target size. It indicates that the window is minimized.
## Testing
Tested in Windows 11.
Previously the split_screen example crashes when the window is
minimized; and with this change, it would not crash. Other behaviors
remain unchanged.
# Objective
- `bundle.rs` is also becoming quite big, let's split it
## Solution
- Split `bundle.rs` into the following:
- `bundle/mod.rs` with the main traits and their documentation
- `bundle/impls.rs` with the main trait implementations for components
and tuples
- `bundle/info.rs` with `BundleInfo` and other types for managing bundle
informations metadata
- `bundle/insert.rs` with code for inserting a bundle into an existing
entity
- `bundle/remove.rs` with code for removing a bundle from an existing
entity
- `bundle/spawner.rs` with code for inserting a bundle on a fresh entity
- `bundle/tests.rs` with code for tests
## Reviewer notes
I suggest reviewing with `--color-moved`, possibly commit-by-commit, in
order to quickly verify that most lines were only moved and not changed.
# Objective
- Extracted from https://github.com/bevyengine/bevy/pull/20099
- Turns out glTF also uses its viewport coordinate system for lights, so
let's account for that
## Solution
- Use the same branch for lights as for cameras when importing glTFs
## Testing
- Ran a dedicated Blender test scene to verify that this is the correct
behavior.
# Objective
Derived `TypePath` impls have a `const _` block in order to hold a `use
alloc::string::ToString` import. But that import is useless.
Avoiding it helps with https://github.com/bevyengine/bevy/issues/19873.
## Solution
Remove the `use` and `const _`.
## Testing
I used cargo expand to confirm the `const _ ` is no longer produced.
`-Zmacro-stats` output tells me this reduces the size of the `Reflect`
code produced for `bevy_ui` from 1_880_486 bytes to 1_859_634 bytes, a
1.1% drop.
## Problem
This pseudocode was triggering constantly, even with the Changed<> query
filter.
```rust
pub fn check_mouse_movement_system(
relative_cursor_positions: Query< &RelativeCursorPosition, (Changed<RelativeCursorPosition>, With<Button>)>,
) {}
```
## Solution
- Added a check to prevent updating the value if it hasn't changed.
---------
Co-authored-by: Giacomo Stevanato <giaco.stevanato@gmail.com>
# Objective
`SystemSetNode` doesn't really add much value beyond a couple helper
functions for getting the name as a string and checking if its a
`SystemTypeSet`. We can replace it entirely and use `InternedSystemSet`
directly by inlining these helper functions' usages without sacrificing
readability.
## Solution
Remove it and replace it with direct `InternedSystemSet` usage.
## Testing
Reusing current tests.
Notifications now include the source entity. This is useful for
callbacks that are responsible for more than one widget.
Part of #19236
This is an incremental change only: I have not altered the fundamental
nature of callbacks, as this is still in discussion. The only change
here is to include the source entity id with the notification.
The existing examples don't leverage this new field, but that will
change when I work on the color sliders PR.
I have been careful not to use the word "events" in describing the
notification message structs because they are not capital-E `Events` at
this time. That may change depending on the outcome of discussions.
@alice-i-cecile
# Objective
- Add 1-bounce RT GI
## Solution
- Implement a very very basic version of ReSTIR GI
https://d1qx31qr3h6wln.cloudfront.net/publications/ReSTIR%20GI.pdf
- Pretty much a copy of the ReSTIR DI code, but adjusted for GI.
- Didn't implement add more spatial samples, or do anything needed for
better quality.
- Didn't try to improve perf at all yet (it's actually faster than DI
though, unfortunately 😅)
- Didn't spend any time cleaning up the shared abstractions between
DI/GI
---
## Showcase
<img width="2564" height="1500" alt="image"
src="https://github.com/user-attachments/assets/1ff7be1c-7d7d-4e53-8aa6-bcec1553db3f"
/>
# Objective
I was building out a diagnostics panel in egui when I noticed that I
could specify the max history length for the
`FrameTimeDiagnosticsPlugin`, but not for the
`EntityCountDiagnosticsPlugin`. The objective was to harmonize the two,
making the diagnostic history length configurable for both.
## Solution
I added a `EntityCountDiagnosticsPlugin::new`, and a `Default` impl that
matches `FrameTimeDiagnosticsPlugin`.
This is a breaking change, given the plugin had no fields previously.
## Testing
I did not test this.
# Objective
Clean up documentation around `UninitializedId`, which has slightly
confusing semantics.
## Solution
Added documentation comments on `UninitializedId`.
---------
Co-authored-by: Chris Russell <8494645+chescock@users.noreply.github.com>
# Objective
- Another step towards unifying our orthonormal basis construction
#20050
- Preserve behavior but fix a bug. Unification will be a followup after
these two PRs and will need more thorough testing.
## Solution
- Make shadow cubemap sampling orthonormalize have the same function
signature as the other orthonormal basis functions in bevy
## Testing
- 3d_scene + lighting examples
# Objective
Picking was changed in the UI transform PR to walk up the tree
recursively to check if an interaction was on a clipped node.
`OverrideClip` only affects a node's local clipping rect, so valid
interactions can be ignored if a node has clipped ancestors.
## Solution
Add a `Without<OverrideClip>` query filter to the picking systems'
`child_of_query`s.
## Testing
This modified `button` example can be used to test the change:
```rust
//! This example illustrates how to create a button that changes color and text based on its
//! interaction state.
use bevy::{color::palettes::basic::*, input_focus::InputFocus, prelude::*, winit::WinitSettings};
fn main() {
App::new()
.add_plugins(DefaultPlugins)
// Only run the app when there is user input. This will significantly reduce CPU/GPU use.
.insert_resource(WinitSettings::desktop_app())
// `InputFocus` must be set for accessibility to recognize the button.
.init_resource::<InputFocus>()
.add_systems(Startup, setup)
.add_systems(Update, button_system)
.run();
}
const NORMAL_BUTTON: Color = Color::srgb(0.15, 0.15, 0.15);
const HOVERED_BUTTON: Color = Color::srgb(0.25, 0.25, 0.25);
const PRESSED_BUTTON: Color = Color::srgb(0.35, 0.75, 0.35);
fn button_system(
mut input_focus: ResMut<InputFocus>,
mut interaction_query: Query<
(
Entity,
&Interaction,
&mut BackgroundColor,
&mut BorderColor,
&mut Button,
&Children,
),
Changed<Interaction>,
>,
mut text_query: Query<&mut Text>,
) {
for (entity, interaction, mut color, mut border_color, mut button, children) in
&mut interaction_query
{
let mut text = text_query.get_mut(children[0]).unwrap();
match *interaction {
Interaction::Pressed => {
input_focus.set(entity);
**text = "Press".to_string();
*color = PRESSED_BUTTON.into();
*border_color = BorderColor::all(RED.into());
// The accessibility system's only update the button's state when the `Button` component is marked as changed.
button.set_changed();
}
Interaction::Hovered => {
input_focus.set(entity);
**text = "Hover".to_string();
*color = HOVERED_BUTTON.into();
*border_color = BorderColor::all(Color::WHITE);
button.set_changed();
}
Interaction::None => {
input_focus.clear();
**text = "Button".to_string();
*color = NORMAL_BUTTON.into();
*border_color = BorderColor::all(Color::BLACK);
}
}
}
}
fn setup(mut commands: Commands, assets: Res<AssetServer>) {
// ui camera
commands.spawn(Camera2d);
commands.spawn(button(&assets));
}
fn button(asset_server: &AssetServer) -> impl Bundle + use<> {
(
Node {
width: Val::Percent(100.0),
height: Val::Percent(100.0),
align_items: AlignItems::Center,
justify_content: JustifyContent::Center,
..default()
},
children![(
Node {
width: Val::Px(0.),
height: Val::Px(0.),
overflow: Overflow::clip(),
..default()
},
children![(
//OverrideClip,
Button,
Node {
position_type: PositionType::Absolute,
width: Val::Px(150.0),
height: Val::Px(65.0),
border: UiRect::all(Val::Px(5.0)),
// horizontally center child text
justify_content: JustifyContent::Center,
// vertically center child text
align_items: AlignItems::Center,
..default()
},
BorderColor::all(Color::WHITE),
BorderRadius::MAX,
BackgroundColor(Color::BLACK),
children![(
Text::new("Button"),
TextFont {
font: asset_server.load("fonts/FiraSans-Bold.ttf"),
font_size: 33.0,
..default()
},
TextColor(Color::srgb(0.9, 0.9, 0.9)),
TextShadow::default(),
)]
)],
)],
)
}
```
On main the button ignores interactions, with this PR it should respond
correctly.
---------
Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
Noticed that we're converting perceptual_roughness to roughness for SSAO
specular occlusion up here, _but_ that happens _before_ we sample the
metallic_roughness texture map. So we're using the wrong roughness. I
assume this is a bug and was not intentional.
Suggest reviewing while hiding the whitespace diff.
## Objective
Fixes#20058
## Solution
Fix the `dynamic_offsets` array being too small if a mesh has morphs and
skins and motion blur, and the renderer isn't using storage buffers
(i.e. WebGL2). The bug was introduced in #13572.
## Testing
- Minimal repro: https://github.com/M4tsuri/bevy_reproduce.
- Also examples `animated_mesh`, `morph_targets`,
`test_invalid_skinned_meshes`.
- As far as I can tell Bevy doesn't have any examples or tests that can
repro the problem combination.
Tested with WebGL and native, Win10/Chrome/Nvidia.
# Objective
- `component.rs` is becoming quite big, let's split it.
## Solution
- Split `component.rs` into the following:
- `component/mod.rs`: the new root of the `component` module: contains
the `Component` trait and a few other very generic items
- `component/clone.rs`: contains component cloning related items
- `component/tick.rs`: contains `Tick` and other tick related items
- future possibilities: move these into `change_detection`; however I
wanted to keep this PR without breaking changes
- `component/register.rs`: contains component registration (included
queued) related items
- `component/required.rs`: contains items and functions for properly
computing required components
- `component/info.rs`: contains items for storing component info and
metadata in the `World`
# Objective
The current Entity Debug impl prints the bit representation. This is an
"overshare". Debug is in many ways the primary interface into Entity, as
people derive Debug on their entity-containing types when they want to
inspect them. The bits take up too much space in the console and
obfuscate the useful information (entity index and generation).
## Solution
Use the Display implementation in Debug as well. Direct people
interested in bits to `Entity::to_bits` in the docs.
# Objective
- Rebase of https://github.com/bevyengine/bevy/pull/12561 , note that
this is blocked on "up-streaming
[iyes_perf_ui](https://crates.io/crates/iyes_perf_ui)" , but that work
seems to also be stalled
> Frame time is often more important to know than FPS but because of the
temporal nature of it, just seeing a number is not enough. Seeing a
graph that shows the history makes it easier to reason about
performance.
## Solution
> This PR adds a bar graph of the frame time history.
>
> Each bar is scaled based on the frame time where a bigger frame time
will give a taller and wider bar.
>
> The color also scales with that frame time where red is at or bellow
the minimum target fps and green is at or above the target maximum frame
rate. Anything between those 2 values will be interpolated between green
and red based on the frame time.
>
> The algorithm is highly inspired by this article:
https://asawicki.info/news_1758_an_idea_for_visualization_of_frame_times
## Testing
- Ran `cargo run --example fps_overlay --features="bevy_dev_tools"`
---------
Co-authored-by: IceSentry <c.giguere42@gmail.com>
Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
# Objective
The extraction systems for materials, meshes, and skins previously
iterated over `RemovedComponents<ViewVisibility>` in addition to more
specific variants like `RemovedComponents<MeshMaterial3d<M>>`. This
caused each system to loop through and check many irrelevant despawned
entities—sometimes multiple times. With many material types, this
overhead added up and became noticeable in frames with many despawns.
<img width="1091" alt="Screenshot 2025-02-21 at 10 28 01 AM"
src="https://github.com/user-attachments/assets/63fec1c9-232c-45f6-9150-daf8751ecf85"
/>
## Solution
This PR removes superfluous `RemovedComponents` iteration for
`ViewVisibility` and `GlobalTransform`, ensuring that we only iterate
over the most specific `RemovedComponents` relevant to the system (e.g.,
material components, mesh components). This is guaranteed to match what
the system originally collected.
### Before (red) / After (yellow):
<img width="838" alt="Screenshot 2025-02-21 at 10 46 17 AM"
src="https://github.com/user-attachments/assets/0e06b06d-7e91-4da5-a919-b843eb442a72"
/>
Log plot to highlight the long tail that this PR is addressing.
# Objective
Make the schedule graph code more understandable, and replace some
panics with `Result`s.
I found the `check_edges` and `check_hierarchy` functions [a little
confusing](https://github.com/bevyengine/bevy/pull/19352#discussion_r2181486099),
as they combined two concerns: Initializing graph nodes for system sets,
and checking for self-edges on system sets. It was hard to understand
the self-edge checks because it wasn't clear what `NodeId` was being
checked against! So, let's separate those concerns, and move them to
more appropriate locations.
Fix a bug where `schedule.configure_sets((SameSet, SameSet).chain());`
would panic with an unhelpful message: `assertion failed: index_a <
index_b`.
## Solution
Remove the `check_edges` and `check_hierarchy` functions, separating the
initialization behavior and the checking behavior and moving them where
they are easier to understand.
For initializing graph nodes, do this on-demand using the `entry` API by
replacing later `self.system_set_ids[&set]` calls with a
`self.system_sets.get_or_add_set(set)` method. This should avoid the
need for an extra pass over the graph and an extra lookup.
Unfortunately, implementing that method directly on `ScheduleGraph`
leads to borrowing errors as it borrows the entire `struct`. So, split
out the collections managing system sets into a separate `struct`.
For checking self-edges, move this check later so that it can be
reported by returning a `Result` from `Schedule::initialize` instead of
having to panic in `configure_set_inner`. The issue was that `iter_sccs`
does not report self-edges as cycles, since the resulting components
only have one node, but that later code assumes all edges point forward.
So, check for self-edges directly, immediately before calling
`iter_sccs`.
This also ensures we catch *every* way that self-edges can be added. The
previous code missed an edge case where `chain()`ing a set to itself
would create a self-edge and would trigger a `debug_assert`.
# Objective
- `bevy_math` allows the `dead_code` lint on some private structs when
`alloc` is not enabled
- allowing lints is not allowed, we should use expect
## Solution
- Don't even compile the code if its expected to be dead instead of
allowing or expecting the lint
# Objective
- `bevy_render_macros` fails to build on its own:
```
error[E0432]: unresolved import `syn::Pat`
--> crates/bevy_render/macros/src/specializer.rs:13:69
|
13 | DeriveInput, Expr, Field, Ident, Index, Member, Meta, MetaList, Pat, Path, Token, Type,
| ^^^
| |
| no `Pat` in the root
| help: a similar name exists in the module: `Path`
|
note: found an item that was configured out
--> /home/runner/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/syn-2.0.104/src/lib.rs:485:15
|
485 | FieldPat, Pat, PatConst, PatIdent, PatLit, PatMacro, PatOr, PatParen, PatPath, PatRange,
| ^^^
note: the item is gated behind the `full` feature
--> /home/runner/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/syn-2.0.104/src/lib.rs:482:7
|
482 | #[cfg(feature = "full")]
| ^^^^^^^^^^^^^^^^
```
## Solution
- Enable the `full` feature of `syn`
# Objective
- bevy_log is not "others". it's part of Bevy
## Solution
- Move it
- Also use the same format as other Bevy dependency (path first) as I
use it in some regexes to run tests on the repo
# Objective
- Related to #19024.
## Solution
- This is a mix of several ways to get rid of weak handles. The primary
strategy is putting strong asset handles in resources that the rendering
code clones into its pipelines (or whatever).
- This does not handle every remaining case, but we are slowly clearing
them out.
## Testing
- `anti_aliasing` example still works.
- `fog_volumes` example still works.
# Objective
The false and true arguments for the select statement in `lerp_hue_long`
are misordered, resulting in it taking the wrong hue path:
## Solution
Swap the arguments around.
Also fixed another case I found during testing. The hue was interpolated
even when it is undefined for one of the endpoints (for example in a
gradient from black to yellow). In those cases it shouldn't interpolate,
instead it should return the hue of the other end point.
## Testing
I added a `linear_gradient` module to the testbed `ui` example, run
with:
```
cargo run --example testbed_ui
```
In the linear gradients screen (press space to switch) it shows a column
of red to yellow linear gradients. The last gradient in the column uses
the OKLCH long path, which should look like this:
matching the same gradient in CSS:
https://jsfiddle.net/fevshkdy/14/
if the correct hue path is chosen.
# Objective
`ThreadLocal::<T>::default()` doesn't require `T: Default`, so
`Parallel<T>` shouldn't require it either.
## Solution
- Replaced the `Default` derive with a manually specified impl.
- Added `Parallel::borrow_local_mut_or` as a non-`T: Default`-requiring
alternative to `borrow_local_mut`.
- Added `Parallel::scope_or` as a non-`T: Default`-requiring alternative
to `scope`.
# Objective
Add interpolation in HSL and HSV colour spaces for UI gradients.
## Solution
Added new variants to `InterpolationColorSpace`: `Hsl`, `HslLong`,
`Hsv`, and `HsvLong`, along with mix functions to the `gradients` shader
for each of them.
#### Limitations
* Didn't include increasing and decreasing path support, it's not
essential and can be done in a follow up if someone feels like it.
* The colour conversions should really be performed before the colours
are sent to the shader but it would need more changes and performance is
good enough for now.
## Testing
```cargo run --example gradients```
## Objective
Fixes#19884.
## Solution
- Add an internal entity command `insert_with`, which takes a function
returning a component and checks if the component would actually be
inserted before invoking the function.
- Add the same check to `insert_from_world`, since it's a similar
situation.
- Update the `or_insert_with`, `or_try_insert_with`, and `or_default`
methods on `EntityEntryCommands` to use the new command.
Since the function/closure returning the component now needs to be sent
into the command (rather than being invoked before the command is
created), the function now has `Send + 'static` bounds. Pretty typical
for command stuff, but I don't know how/if it'll affect existing users.
---------
Co-authored-by: Chris Russell <8494645+chescock@users.noreply.github.com>
# Objective
To implement fmt::Display for the direction types. The reason that this
would be a good addition is that I often find myself using println! to
debug things with directions and adding the extra ":?" was getting a
little annoying. It would also be better for any potential CLI apps that
might need to output a direction.
## Solution
Copied glam's implementation of Display for each length of direction.
I.E Vec3's display for Dir3.
## Testing
- Did you test these changes? If so, how?
Yes, I wrote a little script that printed out the different directions
and compared it to their vector counterparts.
Here it is if anyone's interested
```
use bevy_math::*;
fn main() {
let dir2 = Dir2::from_xy(0.0, 1.0).unwrap();
let dir3 = Dir3::from_xyz(0.0, 1.0, 0.0).unwrap();
let dir3a = Dir3A::from_xyz(0.0, 1.0, 0.0).unwrap();
let dir4 = Dir4::from_xyzw(0.0, 1.0, 0.0, 0.0).unwrap();
let vec2 = Vec2::new(0.0, 1.0);
let vec3 = Vec3::new(0.0, 1.0, 0.0);
let vec4 = Vec4::new(0.0, 1.0, 0.0, 1.0);
println!("{dir2} {dir3} {dir3a} {dir4}");
println!("{vec2}, {vec3}, {vec4}")
}
```
- Are there any parts that need more testing?
Perhaps
