# Objective
- Related to #19024
## Solution
- Use the new `load_shader_library` macro for the shader libraries and
`embedded_asset`/`load_embedded_asset` for the "shader binaries" in
`bevy_gizmos`.
## Testing
- `2d_gizmos` example still works.
- `3d_gizmos` example still works.
P.S. I don't think this needs a migration guide. Technically users could
be using the `pub` weak handles, but there's no actual good use for
them, so omitting it seems fine. Alternatively, we could mix this in
with the migration guide notes for #19137.
# Objective
- Related to #19024
## Solution
- Use the new `load_shader_library` macro for the shader libraries and
`embedded_asset`/`load_embedded_asset` for the "shader binaries" in
`bevy_core_pipeline`.
## Testing
- `bloom_3d` example still works.
- `motion_blur` example still works.
- `meshlet` example still works (it uses a shader from core).
P.S. I don't think this needs a migration guide. Technically users could
be using the `pub` weak handles, but there's no actual good use for
them, so omitting it seems fine. Alternatively, we could mix this in
with the migration guide notes for #19137.
# Objective
Renames `Timer::finished` and `Timer::paused` to `Timer::is_finished`
and `Timer::is_paused` to align the public APIs for `Time`, `Timer`, and
`Stopwatch`.
Fixes#19110
# Objective
Fixes#19385
Note: this has shader errors due to #19383 and should probably be merged
after #19384
## Solution
- Move the example to the UI testbed
- Adjust label contents and cell size so that every test case fits on
the screen
- Minor tidying, slightly less harsh colors while preserving the
intentional debug coloring
## Testing
`cargo run --example testbed_ui`

---------
Co-authored-by: François Mockers <mockersf@gmail.com>
# Objective
Fixes#18905
## Solution
`world.commands().entity(target_entity).queue(command)` calls
`commands.with_entity` without an error handler, instead queue on
`Commands` with an error handler
## Testing
Added unit test
Co-authored-by: Heart <>
# Objective
- Addresses the previous example's lack of visual appeal and clarity. It
was missing labels for clear distinction of the shadow settings used on
each of the shapes. The suggestion in the linked issue was to either
just visually update and add labels or to collapse example to a single
node with adjustable settings.
- Fixes#19240
## Solution
- Replace the previous static example with a single, central node with
adjustable settings as per issue suggestion.
- Implement button-based setting adjustments. Unfortunately slider
widgets don't seem available yet and I didn't want to further bloat the
example.
- Improve overall aesthetics of the example -- although color pallette
could still be improved. flat gray tones are probably not the best
choice as a contrast to the shadow, but the white border does help in
that aspect.
- Dynamically recolor shadows for visual clarity when increasing shadow
count.
- Add Adjustable Settings:
- Shape selection
- Shadow X/Y offset, blur, spread, and count
- Add Reset button to restore default settings
The disadvantage of this solution is that the old example code would
have probably been easier to digest as the new example is quite bloated
in comparison. Alternatively I could also just implement labels and fix
aesthetics of the old example without adding functionality for
adjustable settings, _but_ I personally feel like interactive examples
are more engaging to users.
## Testing
- Did you test these changes? If so, how? `cargo run --example
box_shadow` and functionality of all features of the example.
- Are there any parts that need more testing? Not that I am aware of.
- How can other people (reviewers) test your changes? Is there anything
specific they need to know? Not really, it should be pretty
straightforward just running the new example and testing the feats.
---
## Showcase


---------
Co-authored-by: ickshonpe <david.curthoys@googlemail.com>
# Objective
Remove `ArchetypeComponentId` and `archetype_component_access`.
Following #16885, they are no longer used by the engine, so we can stop
spending time calculating them or space storing them.
## Solution
Remove `ArchetypeComponentId` and everything that touches it.
The `System::update_archetype_component_access` method no longer needs
to update `archetype_component_access`. We do still need to update query
caches, but we no longer need to do so *before* running the system. We'd
have to touch every caller anyway if we gave the method a better name,
so just remove `System::update_archetype_component_access` and
`SystemParam::new_archetype` entirely, and update the query cache in
`Query::get_param`.
The `Single` and `Populated` params also need their query caches updated
in `SystemParam::validate_param`, so change `validate_param` to take
`&mut Self::State` instead of `&Self::State`.
# Objective
- move SyncCell and SyncUnsafeCell to bevy_platform
## Solution
- move SyncCell and SyncUnsafeCell to bevy_platform
## Testing
- cargo clippy works
# Objective
- Related to #19024
## Solution
- Use the new `load_shader_library` macro for the shader libraries and
`embedded_asset`/`load_embedded_asset` for the "shader binaries" in
`bevy_sprite`.
## Testing
- `sprite` example still works.
- `mesh2d` example still works.
P.S. I don't think this needs a migration guide. Technically users could
be using the `pub` weak handles, but there's no actual good use for
them, so omitting it seems fine. Alternatively, we could mix this in
with the migration guide notes for #19137.
# Objective
- A step towards splitting out bevy_camera from bevy_render
## Solution
- Move a shim type into bevy_utils to avoid a dependency cycle
- Manually expand Deref/DerefMut to avoid having a bevy_derive
dependency so early in the dep tree
## Testing
- It compiles
Fixes#19081.
Simply created a duplicate of the existing `insert_if_new` test, but
using sparse sets.
## Testing:
The test passes on main, but fails if #19059 is reverted.
# Objective
- Related to #19024
## Solution
- Use the new `load_shader_library` macro for the shader libraries and
`embedded_asset`/`load_embedded_asset` for the "shader binaries" in
`bevy_anti_aliasing`.
## Testing
- `anti_aliasing` example still works.
P.S. I don't think this needs a migration guide. Technically users could
be using the `pub` weak handles, but there's no actual good use for
them, so omitting it seems fine. Alternatively, we could mix this in
with the migration guide notes for #19137.
# Objective
Found a typo while looking at gradients in another issue and gave the
docs a skim for more.
## Solution
A couple typo fixes and some tiny improvements
# Objective
Constify `Val::resolve` and `BorderRadius::resolve`
# Solution
* Replace uses of `Vec2::min_element` and `Vec2::max_element` with `min`
and `max` called on the components.
* Make `BorderRadius::resolve` and `BorderRadius::resolve_single_corner`
`const`.
* Swap the order of the `bottom_left` and `bottom_right` fields of
`BorderRadius` and `ResolvedBorderRadius` so they match the ccw order
used in the shader and in css.
# Objective
- Enable state scoped entities by default
- Provide a way to disable it when needed
---------
Co-authored-by: Ben Frankel <ben.frankel7@gmail.com>
# Objective
- Related to #19024
## Solution
- Use the new `load_shader_library` macro for the shader libraries and
`embedded_asset`/`load_embedded_asset` for the "shader binaries" in
bevy_render.
## Testing
- `animate_shader` example still works
P.S. I don't think this needs a migration guide. Technically users could
be using the `pub` weak handles, but there's no actual good use for
them, so omitting it seems fine. Alternatively, we could mix this in
with the migration guide notes for #19137.
# Objective
Improve the `tab_navigation` example.
## Solution
* Set different `TabIndex`s for the buttons of each group.
* Label each button with its associated `TabIndex`.
* Reduce the code duplication using a loop.
I tried to flatten it further using the new spawning APIs and
`children!` macro but not sure what the current best way to attach the
observers is.
# Objective
Allow creating a new window without it being focused, when `Window`'s
`focused` is `false.
## Solution
Use `winit`'s `WindowBuilder`'s `with_active` method
## Notes
- `winit`'s doc lists [redox's
`Orbital`](https://gitlab.redox-os.org/redox-os/orbital) as an
unsupported platform, but since Bevy doesn't officially support this
platform, I didn't put it in the documentation.
- I only tested on Linux, which is an unsupported platform. I can give
you a test code if you want to test on another platform.
- I initially put a line
[here](https://github.com/bevyengine/bevy/blob/v0.11.0/crates/bevy_winit/src/system.rs#L72)
to set the Bevy `Window`'s `focused` to `winit_window.has_focus()` after
window creation to avoid the case where `with_active` is not supported,
the window is spawned focused, no `WindowFocused` event is triggered,
and Bevy `Window` would be desynced from winit's window. But after
testing on Linux (which doesn't support `with_active`) it seems like at
that point `has_focus` returns `false` and the event is triggered, so I
removed it. Do you think I should add it back to be safe?
## Changelog
- A new unfocused `Window` can be created by setting `focused` to
`false`.
## Migration Guide
- If a `Window` is spawned with `focused` set to `false`, it will now
start not focused on supported platforms.
Adopted from #9208
---------
Co-authored-by: Sélène Amanita <selene.amanita@net-c.com>
Co-authored-by: Sélène Amanita <134181069+Selene-Amanita@users.noreply.github.com>
Co-authored-by: atlv <email@atlasdostal.com>
Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
# Objective
In #19253 we pinned nightly due to a bug in Miri. That issue was
resolved and the latest Miri should be usable for us again.
## Solution
- Use latest nightly again
## Testing
- I tested today's Miri locally with
`RUSTUP_TOOLCHAIN=nightly-2025-05-18 MIRIFLAGS="-Zmiri-ignore-leaks
-Zmiri-disable-isolation" RUSTFLAGS="-Zrandomize-layout" cargo miri test
-p bevy_ecs`
# Objective
Fix some grammatical errors: it's -> its
Not the most useful commit in the world, but I saw a couple of these and
decided to fix the lot.
## Solution
-
## Testing
-
# Objective
Fix https://github.com/bevyengine/bevy/issues/13390
## Solution
The second parameter of the remove_reflect function is called
component_type_name in ReflectCommandExt but component_type_path in the
implementation for EntityCommands. Use component_type_path in both
places.
## Testing
None
# Objective
We want to extend our examples with a new category "usage" to
demonstrate common use cases (see bevyengine/bevy-website#2131). This PR
adds an example of animated cooldowns on button clicks.
## Solution
- New example in "usage" directory
- Implement a cooldown with an animated child Node
## Testing
- I ran this on Linux
- [x] test web (with bevy CLI: `bevy run --example cooldown web --open`)
---------
Co-authored-by: Thierry Berger <contact@thierryberger.com>
Co-authored-by: Ida "Iyes" <40234599+inodentry@users.noreply.github.com>
# Objective
cargo update was required to build because into_values was added in a
patch version
## Solution
Depend on the new patch
## Testing
Builds locally now
# Objective
Fixes#17983
## Solution
Implemented a basic `Dir4` struct with methods similar to `Dir3` and
`Dir2`.
## Testing
- Did you test these changes? If so, how?
Added unit tests that follow the same pattern of the other Dir structs.
- Are there any parts that need more testing?
Since the other Dir structs use rotations to test renormalization and I
have been following them as a pattern for the Dir4 struct I haven't
implemented a test to cover renormalization of Dir4's.
- How can other people (reviewers) test your changes? Is there anything
specific they need to know?
Use Dir4 in the wild.
- If relevant, what platforms did you test these changes on, and are
there any important ones you can't test?
N/A (Tested on Linux/X11 but it shouldn't be a problem)
# Objective
Fixes#19156
## Solution
There was a call to sort by `TabIndex` after iterating through all the
`TabGroup`s. Simply removing that line of code made the new test case
pass (navigating through `TabIndex` within different `TabGroup`s and
kept everything else working as expected as far as I can tell.
I went ahead and broke the `focusable` vec down into per-group vecs that
get sorted by `TabIndex` and appended to the main vec in group sorted
order to maintain the sorting that was being done before, but respecting
the `TabGroup` sorting that was missing in the issue that this PR
addresses.
## Testing
I added a new unit test that reproduced the issue outlined above that
will run in CI. This test was failing before deleting the sort, and now
both unit tests are passing.
# Objective
Fixes#18790.
Simpler alternative to #19195.
## Solution
As suggested by @PixelDust22, simply avoid overwriting the pass if the
schedule already has auto sync points enabled.
Leave pass logic untouched.
It still is probably a bad idea to add systems/set configs before
changing the build settings, but that is not important as long there are
no more complex build passes.
## Testing
Added a test.
---------
Co-authored-by: Thierry Berger <contact@thierryberger.com>
# Objective
- The WakeUp event is never added to the app. If you need to use that
event you currently need to add it yourself.
## Solution
- Add the WakeUp event to the App in the WinitPlugin
## Testing
- I tested the window_setting example and it compiled and worked
# Objective
- Simplify `Camera` initialization
- allow effects to require HDR
## Solution
- Split out `Camera.hdr` into a marker `Hdr` component
## Testing
- ran `bloom_3d` example
---
## Showcase
```rs
// before
commands.spawn((
Camera3d
Camera {
hdr: true
..Default::default()
}
))
// after
commands.spawn((Camera3d, Hdr));
// other rendering components can require that the camera enables hdr!
// currently implemented for Bloom, AutoExposure, and Atmosphere.
#[require(Hdr)]
pub struct Bloom;
```
[Explanation](https://bevyengine.org/learn/contribute/helping-out/explaining-examples/)
for the 2d shapes example, taken from the original HackMD document and
edited a bit.
This example is a strange one, it's eye-catching mostly because it's the
first example (at time of writing) in the examples page. That being
said, the example does a decent amount of teaching utility to it: we can
explain the bevy math-shape to mesh pipeline, which illuminates a way of
transforming one form of data (abstract, mathematical shape
descriptions) into another (meshes) which may be novel or inspirational
to some users.
---------
Co-authored-by: theotherphil <phil.j.ellison@gmail.com>
> [!important]
> To **maintainers**: we should wait to merge this one in until after
#18944 lands so that cherry-picking the latter for 0.16.1 is simpler.
# Objective
The `std` module is where we implement the reflection traits for types
that are exported from `std` (including `core` and `alloc`). Over time,
this file has grown increasingly large, making it difficult to navigate
and a pain point for merge conflicts.
The goal of this PR is to break up the module into smaller chunks.
## Solution
The `std` module has been split into many submodules:
- `alloc`
- `bevy_platform`
- `core`
- `std`
Each of these new modules is comprised of submodules that closely
resemble the actual module. For example, the impls for
`::alloc::vec::Vec` have been moved to
`bevy_reflect::impls::alloc::vec::Vec`.
Some liberties were taken. For example, `Cow<'static, Path>` was kept in
`bevy_reflect::impls::std::path` rather than
`bevy_reflect::impls::alloc::borrow`.
You may ask: _Isn't this a little overkill? Why does the one-line impl
for `TypeId` need its own file?_
And yes, it is partly overkill. But the benefit with this approach is
that where an `std`-related type should live is mostly unambiguous. If
we wanted to reflect `::core::net::Ipv4Addr`, it's very clear that it
should be done in `bevy_reflect::impls::core::net`.
We can discuss better ways of breaking this up if people have other
ideas or opinions, but I think this is a pretty straightforward way of
doing it.
### Note to Reviewers
The code is pretty much copy-paste from the mega module to the new
submodules. It's probably best to focus efforts on reviewing the general
module structure, as well as maybe which impls are included where.
You _can_ review the code contained within each impl, but I promise you
the only thing I touched were the paths in the macros so they could be
more hygienic :)
## Testing
You can just check that everything compiles still:
```
cargo check -p bevy_reflect --tests
```
# Objective
- The tigger_screenshots system gets added in `.build()` but relies on a
resource that is only inserted in `.finish()`
- This isn't a bug for most users, but when doing headless mode testing
it can technically work without ever calling `.finish()` and did work
before bevy 0.15 but while migrating my work codebase I had an issue of
test failing because of this
## Solution
- Move the trigger_screenshots system to `.finish()`
## Testing
- I ran the screenshot example and it worked as expected
# Objective
- Allow compressed image formats to be used with `ImagePlugin` and
`GltfPlugin` in cases where there is no `RenderDevice` resource. (For
example, when using a custom render backend)
## Solution
- Define a `CompressedImageFormatSupport` component that allows the user
to explicitly determine which formats are supported.
~~Not sure if this is the best solution. Alternatively, I considered
initializing CompressedImageFormatSupport from render device features
separately, it would need to run after the render device is initialized
but before `ImagePlugin` and `GltfPlugin` finish. Not sure where the
best place for that to happen would be.~~
Update: decided on going with @greeble-dev solution: defining the
`CompressedImageFormatSupport` resource in `bevy_image`, but letting
`bevy_render` register the resource value.
## produce a DragEnter event when reentering the dragged entity
when making a piano, i want dragging across the keys to trigger the
notes of each key, but currently if i drag out of a key, then back to
it, this will not work since the dragged entity gets filtered out
## Solution
- make DragEnter event work whenever there's an entry. if the user wants
to ignore the dragged entity they can compare `target` and `dragged`
## Testing
- tested this with a modified version of the 2d_shapes example. i added
an observer to the entities: (and added mesh picking plugin)
```rust
.observe(|t: Trigger<Pointer<DragEnter>>| {
info!("entered {}, started from {}", t.target(), t.dragged);
}
```
- i'm not sure if other things need more testing, or if this is wrong
completely and breaks other things i don't know of!
---
## Showcase
before:
https://github.com/user-attachments/assets/48de606a-e44d-4ca1-ae16-d8dcef640d6e
after:
https://github.com/user-attachments/assets/b1be231f-c826-47bc-be43-c637f22e7846
# Objective
When user presses <kbd>3</kbd>, the falloff mode should be changed to
`ExponentialSquared` as described in the instructions, but it's not in
fact.
Online Example: https://bevyengine.org/examples-webgpu/3d-rendering/fog/
## Solution
Change it to `ExponentialSquared`
## Testing
- Did you test these changes? If so, how?
Yes, by `cargo run --example fog`
- Are there any parts that need more testing?
No.
- How can other people (reviewers) test your changes? Is there anything
specific they need to know?
```
cargo run --example fog
```
- If relevant, what platforms did you test these changes on, and are
there any important ones you can't test?
N/A
# Objective
- Allow users to get the playback position of playing audio.
## Solution
- Add a `position` method to `AudioSinkPlayback`
- Implement it for `AudioSink` and `SpatialAudioSink`
## Testing
- Updated `audio_control` example to show playback position