Commit Graph

8574 Commits

Author SHA1 Message Date
Zachary Harrold
a8568f7535
Ensure dds enables bevy_core_pipeline/dds in bevy_anti_aliasing (#18484)
# Objective

- Compile failure with `bevy_anti_aliasing` due to `dds` feature not
enabling `bevy_core_pipeline/dds`, causing a public API desync.

## Solution

- Ensured feature is enabled

## Testing

- CI
2025-03-22 12:27:14 +00:00
Zachary Harrold
e3968e2963
Properly gate imports in bevy_scene (#18482)
# Objective

- Some imports are only used with certain features.

## Solution

- Gate them!

## Testing

- CI
2025-03-22 12:22:20 +00:00
Zachary Harrold
2eb836abaf
Fix clippy::let_and_return in bevy_ecs (#18481)
# Objective

- `clippy::let_and_return` fails in `bevy_ecs`

## Solution

- Fixed it!

## Testing

- CI
2025-03-22 11:48:40 +00:00
Zachary Harrold
72b4ed05c7
Address clippy::let_and_return in bevy_utils (#18480)
# Objective

`clippy::let_and_return` fails on Windows.

## Solution

Fixed it!

## Testing

- CI
2025-03-22 11:44:49 +00:00
Zachary Harrold
4127ac1662
Properly gate functionality on http in bevy_remote (#18478)
# Objective

Noticed that `bevy_remote` fails to compile without default features.

## Solution

Adjusted offending method to avoid reliance on `http` module when it is
disabled.

## Testing

- CI
- `cargo clippy -p bevy_remote --no-default-features`
2025-03-22 11:26:36 +00:00
Zachary Harrold
c87eeed6d8
Address lints in bevy_platform_support (#18477)
# Objective

@mockersf noticed there were some failing lints in
`bevy_platform_support`.

## Solution

Addressed the lints!

## Testing

- CI
2025-03-22 11:21:18 +00:00
Brezak
1b82f1fae8
Fix clippy warning about unnecessary return in single_threaded_taks_pool.rs (#18472)
# Objective

Every time I run `cargo clippy -p bevy_ecs` it pops up and it's
distracting.

## Solution

Removed unnecessary returns. The blocks themselves are necessary or the
`#[cfg(...)]` doesn't apply properly

## Testing

`cargo clippy -p bevy_ecs` + ci build tests
2025-03-22 09:03:29 +00:00
kirawulff
716fc8b54b
Fix double-despawning in despawn_world and despawn_world_recursive benchmarks (#18448)
# Objective

- Fixes #18430


## Solution

- Moves world creation into per-iteration setup for both `despawn_world`
and `despawn_world_recursive`, meaning the world's entities don't aren't
despawned multiple times
- Doesn't affect despawn APIs

## Testing

- Tested manually by running `cargo bench -p benches --bench ecs --
despawn_world`
2025-03-22 03:26:34 +00:00
ickshonpe
84b09b9398
Newtype Anchor (#18439)
# Objective

The `Anchor` component doesn't need to be a enum. The variants are just
mapped to `Vec2`s so it could be changed to a newtype with associated
const values, saving the space needed for the discriminator by the enum.

Also there was no benefit I think in hiding the underlying `Vec2`
representation of `Anchor`s.

Suggested by @atlv24.

Fixes #18459
Fixes #18460

## Solution

Change `Anchor` to a struct newtyping a `Vec2`, and its variants into
associated constants.

## Migration Guide

The anchor component has been changed from an enum to a struct newtyping
a `Vec2`. The `Custom` variant has been removed, instead to construct a
custom `Anchor` use its tuple constructor:
```rust
Sprite {
     anchor: Anchor(Vec2::new(0.25, 0.4)),
     ..default()
}
```
The other enum variants have been replaced with corresponding constants:
* `Anchor::BottomLeft` to `Anchor::BOTTOM_LEFT`
* `Anchor::Center` to `Anchor::CENTER`
* `Anchor::TopRight` to `Anchor::TOP_RIGHT`
* .. and so on for the remaining variants
2025-03-21 22:27:11 +00:00
krunchington
9ae7aa4399
Update testbed_ui to use Improved Spawning API (#18329)
# Objective

Contributes to #18238 
Updates the `text2d`, example to use the `children!` macro.

~~The SpawnIter usage in this example is maybe not the best. Very open
to opinions. I even left one `with_children` that I thought was just
much better than any alternative.~~

## Solution

Updates examples to use the Improved Spawning API merged in
https://github.com/bevyengine/bevy/pull/17521

## Testing

- Did you test these changes? If so, how?
- Opened the examples before and after and verified the same behavior
was observed. I did this on Ubuntu 24.04.2 LTS using `--features
wayland`.
- Are there any parts that need more testing?
- Other OS's and features can't hurt, but this is such a small change it
shouldn't be a problem.
- How can other people (reviewers) test your changes? Is there anything
specific they need to know?
  - Run the examples yourself with and without these changes.
- If relevant, what platforms did you test these changes on, and are
there any important ones you can't test?
  - see above

---

## Showcase

n/a

## Migration Guide

n/a
2025-03-21 19:32:12 +00:00
Alice Cecile
116484b37b
Fix missed error_handling example rename and update description (#18455)
# Objective

I didn't rename the example properly in the meta data, and the
description is unclear and limited.

## Solution

Fix both of those.
2025-03-21 02:15:37 +00:00
Carter Anderson
a033f1b206
Replace VisitEntities with MapEntities (#18432)
# Objective

There are currently too many disparate ways to handle entity mapping,
especially after #17687. We now have MapEntities, VisitEntities,
VisitEntitiesMut, Component::visit_entities,
Component::visit_entities_mut.

Our only known use case at the moment for these is entity mapping. This
means we have significant consolidation potential.

Additionally, VisitEntitiesMut cannot be implemented for map-style
collections like HashSets, as you cant "just" mutate a `&mut Entity`.
Our current approach to Component mapping requires VisitEntitiesMut,
meaning this category of entity collection isn't mappable. `MapEntities`
is more generally applicable. Additionally, the _existence_ of the
blanket From impl on VisitEntitiesMut blocks us from implementing
MapEntities for HashSets (or any types we don't own), because the owner
could always add a conflicting impl in the future.

## Solution

Use `MapEntities` everywhere and remove all "visit entities" usages.

* Add `Component::map_entities`
* Remove `Component::visit_entities`, `Component::visit_entities_mut`,
`VisitEntities`, and `VisitEntitiesMut`
* Support deriving `Component::map_entities` in `#[derive(Coomponent)]`
* Add `#[derive(MapEntities)]`, and share logic with the
`Component::map_entities` derive.
* Add `ComponentCloneCtx::queue_deferred`, which is command-like logic
that runs immediately after normal clones. Reframe `FromWorld` fallback
logic in the "reflect clone" impl to use it. This cuts out a lot of
unnecessary work and I think justifies the existence of a pseudo-command
interface (given how niche, yet performance sensitive this is).

Note that we no longer auto-impl entity mapping for ` IntoIterator<Item
= &'a Entity>` types, as this would block our ability to implement cases
like `HashMap`. This means the onus is on us (or type authors) to add
explicit support for types that should be mappable.

Also note that the Component-related changes do not require a migration
guide as there hasn't been a release with them yet.

## Migration Guide

If you were previously implementing `VisitEntities` or
`VisitEntitiesMut` (likely via a derive), instead use `MapEntities`.
Those were almost certainly used in the context of Bevy Scenes or
reflection via `ReflectMapEntities`. If you have a case that uses
`VisitEntities` or `VisitEntitiesMut` directly, where `MapEntities` is
not a viable replacement, please let us know!

```rust
// before
#[derive(VisitEntities, VisitEntitiesMut)]
struct Inventory {
  items: Vec<Entity>,
  #[visit_entities(ignore)]
  label: String,
}

// after
#[derive(MapEntities)]
struct Inventory {
  #[entities]
  items: Vec<Entity>,
  label: String,
}
```
2025-03-21 00:18:10 +00:00
Wuketuke
55fd10502c
Required components accept const values (#16720) (#18309)
# Objective

Const values should be more ergonomic to insert, since this is too
verbose
``` rust
#[derive(Component)]
#[require(
    LockedAxes(||LockedAxes::ROTATION_LOCKED),
)]
pub struct CharacterController;
```
instead, users can now abbreviate that nonsense like this
``` rust
#[derive(Component)]
#[require(
    LockedAxes = ROTATION_LOCKED),
)]
pub struct CharacterController;
```
it also works for enum labels.
I chose to omit the type, since were trying to reduce typing here. The
alternative would have been this:
```rust
#[require(
    LockedAxes = LockedAxes::ROTATION_LOCKED),
)]
```
This of course has its disadvantages, since the const has to be
associated, but the old closure method is still possible, so I dont
think its a problem.
- Fixes #16720

## Testing

I added one new test in the docs, which also explain the new change. I
also saw that the docs for the required components on line 165 was
missing an assertion, so I added it back in

---------

Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
2025-03-21 00:02:10 +00:00
krunchington
dac0b1019a
Update sprite_slice, spatial_audio_3d, spatial_audio_2d examples to use children macro (#18318)
# Objective

Contributes to #18238 
Updates the `sprite_slice`, `spatial_audio_3d` and `spatial_audio_2d`
examples to use the `children!` macro.

## Solution

Updates examples to use the Improved Spawning API merged in
https://github.com/bevyengine/bevy/pull/17521

## Testing

- Did you test these changes? If so, how?
- Opened the examples before and after and verified the same behavior
was observed. I did this on Ubuntu 24.04.2 LTS using `--features
wayland`.
- Are there any parts that need more testing?
- Other OS's and features can't hurt, but this is such a small change it
shouldn't be a problem.
- How can other people (reviewers) test your changes? Is there anything
specific they need to know?
  - Run the examples yourself with and without these changes.
- If relevant, what platforms did you test these changes on, and are
there any important ones you can't test?
  - see above

---

## Showcase

n/a

## Migration Guide

n/a
2025-03-20 23:38:12 +00:00
Lucas Franca
acd4451151
Fix warning spam on mesh2d_manual example (#18433)
# Objective

Fixes #18429 

## Solution

Add syncing to the render world for the `ColoredMesh2d` component

## Testing

Ran the example and it works as intended without the warning spam
2025-03-20 20:05:57 +00:00
kirawulff
398e011778
Fix incorrect command given by the benchmarking README (#18431)
Note: Fixing this caused me to open #18430. On the whole, this fix and
that bug don't really depend on each other, so I'm opening this PR
anyways

# Objective

- Fixes #18387 

## Solution

- Very small update to benchmarking documentation
- Checked through to ensure consistency with other documentation. The
only other mention of benchmarking commands I could find is a comment in
the `Cargo.toml` associated with the benchmarking; the correct command
is already listed there.

## Testing

- Manual testing on command line using updated commands
- Caused me to see #18430
2025-03-20 20:05:02 +00:00
Alice Cecile
d837b9e19b
Establish structure and process for in-repo release notes (#18427)
# Objective

As discussed in #https://github.com/bevyengine/bevy/discussions/16431,
our release process is a major bottleneck, difficult to collaborate on
and a serious source of burnout (hi!). Writing all of the release notes
and migration guides at the end of the cycle is miserable, and makes it
harder to coalesce them across multiple PRs doing related work.

## Solution

This PR largely implements the solution designed and discussed in the
[Better release
notes](https://discord.com/channels/691052431525675048/1331412459432710247)
working group, unofficially led by @NthTensor. The
[plan](https://hackmd.io/NBKkrGbbS5CaU7PsQUFGJQ) laid out in the linked
HackMD has largely been folllowed, although I've also added Migration
Guides too: they suffer much the same problem.

I've also moved away from using the PR number as the title for the file:
if we're hand-authoring the files we can do much better than that!

The READMEs for each folder describe the process in more detail: please
read (and comment on them!).

## Questions for reviewers / fellow implementers

- I've moved away from the current "store metadata in a mega-file"
approach, and moved it towards a "put the metadata in the file you're
editing" design. I much prefer the locality, but it may be harder to get
to play nice with our website generation. Do you want me to revert that?
See [this
folder](https://github.com/bevyengine/bevy-website/tree/main/release-content/0.15)
for the current format.
- does the "how to write release notes / migration guides" sections make
sense to you here? Normally I would toss this in the Contributor's
Guide, but I do like it being right beside the spot you're making
changes

## Follow-up work

- [ ] add a job which checks for the labels and blocks the PR if no file
in the correct folder is merged
- [ ] add a CI job to do basic format validation on the files inside of
these folders
- [ ] generate the release notes and migration guides using a modified
version of [the
tooling](https://github.com/bevyengine/bevy-website/tree/main/generate-release)
one last time for 0.16
- [ ] remove the release notes and migration guide generating tools
- [ ] build a new pipeline to turn the copy-pasted release notes here
into actual website content
- [ ] rethink how we're doing release notes to provide better punchy
summaries for casual readers
- [ ] create a CI job that checks for new or edited migration guides and
automatically labels the PR

---------

Co-authored-by: Joona Aalto <jondolf.dev@gmail.com>
Co-authored-by: Zachary Harrold <zac@harrold.com.au>
2025-03-20 04:26:20 +00:00
Brezak
90ce1ee07c
Add more methods to RelationshipSourceCollection (#18421)
# Objective

While working on #18058 I realized I could use
`RelationshipTargetCollection::new`, so I added it.

## Solution

- Add `RelationshipTargetCollection::new`
- Add `RelationshipTargetCollection::reserve`. Could generally be useful
when doing micro-optimizations.
- Add `RelationshipTargetCollection::shrink_to_fit`. Rust collections
generally don't shrink when removing elements. Might be a good idea to
call this once in a while.

## Testing

`cargo clippy`

---

## Showcase

`RelationshipSourceCollection` now implements `new`, `reserve` and
`shrink_to_fit` to give greater control over how much memory it
consumes.

## Migration Guide

Any type implementing `RelationshipSourceCollection` now needs to also
implement `new`, `reserve` and `shrink_to_fit`. `reserve` and
`shrink_to_fit` can be made no-ops if they conceptually mean nothing to
a collection.

---------

Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
Co-authored-by: Chris Russell <8494645+chescock@users.noreply.github.com>
2025-03-20 01:35:51 +00:00
robtfm
655ee4b120
Gltf handle missing bindposes (#18419)
# Objective

correctly load gltfs without explicit bindposes

## Solution

use identity matrices if bindposes are not found.

note: currently does nothing, as gltfs without explicit bindposes fail
to load, see <https://github.com/gltf-rs/gltf/pull/449>

---------

Co-authored-by: François Mockers <francois.mockers@vleue.com>
2025-03-19 21:45:05 +00:00
Brezak
28907ae171
Add methods to bulk replace relationships on a entity (#18058)
# Objective

Add a way to efficiently replace a set of specifically related entities
with a new set.
Closes #18041 

## Solution

Add new `replace_(related/children)` to `EntityWorldMut` and friends.

## Testing

Added a new test to `hierarchy.rs` that specifically check if
`replace_children` actually correctly replaces the children on a entity
while keeping the original one.

---

## Showcase

`EntityWorldMut` and `EntityCommands` can now be used to efficiently
replace the entities a entity is related to.

```rust
/// `parent` has 2 children. `entity_a` and `entity_b`.
assert_eq!([entity_a, entity_b], world.entity(parent).get::<Children>());

/// Replace `parent`s children with `entity_a` and `entity_c`
world.entity_mut(parent).replace_related(&[entity_a, entity_c]);

/// `parent` now has 2 children. `entity_a` and `entity_c`.
///
/// `replace_children` has saved time by not removing and reading
/// the relationship between `entity_a` and `parent`
assert_eq!([entity_a, entity_c], world.entity(parent).get::<Children>());

---------

Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
2025-03-19 20:04:42 +00:00
Greeble
2aaac934b5
Fix bevy_ecs doc tests with --all-features (#18424)
## Objective

Fix `bevy_ecs` doc tests failing when used with `--all-features`.

```
---- crates\bevy_ecs\src\error\handler.rs - error::handler::GLOBAL_ERROR_HANDLER (line 87) stdout ----
error[E0425]: cannot find function `default_error_handler` in this scope
 --> crates\bevy_ecs\src\error\handler.rs:92:24
  |
8 |    let error_handler = default_error_handler();
  |                        ^^^^^^^^^^^^^^^^^^^^^ not found in this scope
```

I happened to come across this while testing #12207. I'm not sure it
actually needs fixing but seemed worth a go

## Testing

```
cargo test --doc -p bevy_ecs --all-features
```

## Side Notes

The CI misses this error as it doesn't use `--all-features`. Perhaps it
should?

I tried adding `--all-features` to `ci/src/commands/doc_tests.rs` but
this triggered a linker error:

```
Compiling bevy_dylib v0.16.0-dev (C:\Projects\bevy\crates\bevy_dylib)
error: linking with `link.exe` failed: exit code: 1189
= note: LINK : fatal error LNK1189: library limit of 65535 objects exceeded␍
```
2025-03-19 20:02:33 +00:00
Asier Illarramendi
faef6d18e2
Split example file docblock and code when generating web examples markdown (#18191)
# Objective

Separate example explanation (file docblock) and the code so they can be
layout differently in the website and we can give a higher importance to
the explanation on the [website search
tool](https://github.com/bevyengine/bevy-website/pull/1935). This would
also allow us to improve the examples so they become even more like a
cookbook.

## Solution

Update the `example-showcase` tool to extract the example file docblock
and write it as the example markdown content. This allows us to access
the explanation via `page.content` in Zola.

## Testing

I've checked that the output is correct after running the tool and it
doesn't throw any error. I've also validated that the approach will work
on the website.

## Showcase

This is a quick and dirty example of what we could do in the web
examples after the change. When we implement the real thing we can put
the explanation on a sidebar or explore other layout options.

<img width="1362" alt="image"
src="https://github.com/user-attachments/assets/6738542e-31c3-41cd-972a-7fa2e942e85d"
/>
2025-03-19 20:01:37 +00:00
IceSentry
06bae05ba2
Add bevy_anti_aliasing (#18323)
# Objective

- bevy_core_pipeline is getting really big and it's a big bottleneck for
compilation time. A lot of parts of it can be broken up

## Solution

- Add a new bevy_anti_aliasing crate that contains all the anti_aliasing
implementations
- I didn't move any MSAA related code to this new crate because that's a
lot more invasive

## Testing

- Tested the anti_aliasing example to make sure all methods still worked

---

## Showcase

 before:

![image](https://github.com/user-attachments/assets/eac18276-2cb9-41c9-aaf4-a5da643a7ba7)

after:

![image](https://github.com/user-attachments/assets/59cb2fb4-306f-4e42-b156-d5534da5685d)

Notice that now bevy_core_pipeline is 1s shorter and bevy_anti_aliasing
now compiles in parallel with bevy_pbr.

## Migration Guide

When using anti aliasing features, you now need to import them from
`bevy::anti_aliasing` instead of `bevy::core_pipeline`
2025-03-19 18:40:32 +00:00
JMS55
f353cc3340
Fix specialize_shadows system ordering (#18412)
# Objective
- Fixes https://github.com/bevyengine/bevy/issues/18332

## Solution

- Move specialize_shadows to ManageViews so that it can run after
prepare_lights, so that shadow views exist for specialization.
- Unfortunately this means that specialize_shadows is no longer in
PrepareMeshes like the rest of the specialization systems.

## Testing
- Ran anti_aliasing example, switched between the different AA options,
observed no glitches.
2025-03-19 06:40:45 +00:00
charlotte
8d5474a2f2
Fix unecessary specialization checks for apps with many materials (#18410)
# Objective

For materials that aren't being used or a visible entity doesn't have an
instance of, we were unnecessarily constantly checking whether they
needed specialization, saying yes (because the material had never been
specialized for that entity), and failing to look up the material
instance.

## Solution

If an entity doesn't have an instance of the material, it can't possibly
need specialization, so exit early before spending time doing the check.

Fixes #18388.
2025-03-19 06:22:39 +00:00
François Mockers
a5ba2ed036
enable std when building bevy_dylib (#18405)
# Objective

- bevy_dylib fails to build:
```
   Compiling bevy_dylib v0.16.0-rc.1 (/bevy/crates/bevy_dylib)
error: linking with `cc` failed: exit status: 1
  |
  = note: some arguments are omitted. use `--verbose` to show all linker arguments
  = note: Undefined symbols for architecture arm64:
            "__critical_section_1_0_acquire", referenced from:
                critical_section::with::h00cfbe529dea9dc9 in libbevy_tasks-53c9db6a3865f250.rlib[58](bevy_tasks-53c9db6a3865f250.evom2xwveqp508omiiqb25xig.rcgu.o)
            "__critical_section_1_0_release", referenced from:
                core::ptr::drop_in_place$LT$critical_section..with..Guard$GT$::hfa034e0208e1a49d in libbevy_tasks-53c9db6a3865f250.rlib[48](bevy_tasks-53c9db6a3865f250.d9dwgpd0156zfn2h5z5ff94zn.rcgu.o)
          ld: symbol(s) not found for architecture arm64
          clang: error: linker command failed with exit code 1 (use -v to see invocation)
```

## Solution

- enable `std` when building bevy_dylib

---------

Co-authored-by: Zachary Harrold <zac@harrold.com.au>
2025-03-19 00:49:26 +00:00
François Mockers
a24691a115
gate import on bevy_animation in bevy_gltf (#18403)
# Objective

- `collect_path` is only declared when feature `bevy_animation` is
enabled
- it is imported without checking for the feature, not compiling when
not enabled

## Solution

- Gate the import
2025-03-18 23:27:46 +00:00
Carter Weinberg
821f6fa0dd
Small Docs PR for Deferred Worlds (#18384)
# Objective

I was looking over a PR yesterday, and got confused by the docs on
deferred world. I thought I would add a little more detail to the struct
in order to clarify it a little.

## Solution

Document some more about deferred worlds.
2025-03-18 20:30:49 +00:00
Alice Cecile
5ab0456f61
Unified picking cleanup (#18401)
# Objective

@cart noticed some issues with my work in
https://github.com/bevyengine/bevy/pull/17348#discussion_r2001815637,
which I somehow missed before merging the PR.

## Solution

- feature gate the UiPickingPlugin correctly
- don't manually add the picking plugins

## Testing

Ran the debug_picking and sprite_picking examples (for UI and sprites
respectively): both seem to work fine.
2025-03-18 20:28:03 +00:00
Eagster
339914b0af
Fix dynamic scene resources not being entity mapped (#18395)
# Objective

The resources were converted via `clone_reflect_value` and the cloned
value was mapped. But the value that is inserted is the source of the
clone, which was not mapped.

I ran into this issue while working on #18380. Having non consecutive
entity allocations has caught a lot of bugs.

## Solution

Use the cloned value for insertion if it exists.
2025-03-18 20:04:55 +00:00
Alice Cecile
5d0505a85e
Unify and simplify command and system error handling (#18351)
# Objective

- ECS error handling is a lovely flagship feature for Bevy 0.16, all in
the name of reducing panics and encouraging better error handling
(#14275).
- Currently though, command and system error handling are completely
disjoint and use different mechanisms.
- Additionally, there's a number of distinct ways to set the
default/fallback/global error handler that have limited value. As far as
I can tell, this will be cfg flagged to toggle between dev and
production builds in 99.9% of cases, with no real value in more granular
settings or helpers.
- Fixes #17272

## Solution

- Standardize error handling on the OnceLock global error mechanisms
ironed out in https://github.com/bevyengine/bevy/pull/17215
- As discussed there, there are serious performance concerns there,
especially for commands
- I also think this is a better fit for the use cases, as it's truly
global
- Move from `SystemErrorContext` to a more general purpose
`ErrorContext`, which can handle observers and commands more clearly
- Cut the superfluous setter methods on `App` and `SubApp`
- Rename the limited (and unhelpful) `fallible_systems` example to
`error_handling`, and add an example of command error handling

## Testing

Ran the `error_handling` example.

## Notes for reviewers

- Do you see a clear way to allow commands to retain &mut World access
in the per-command custom error handlers? IMO that's a key feature here
(allowing the ad-hoc creation of custom commands), but I'm not sure how
to get there without exploding complexity.
- I've removed the feature gate on the default_error_handler: contrary
to @cart's opinion in #17215 I think that virtually all apps will want
to use this. Can you think of a category of app that a) is extremely
performance sensitive b) is fine with shipping to production with the
panic error handler? If so, I can try to gather performance numbers
and/or reintroduce the feature flag. UPDATE: see benches at the end of
this message.
- ~~`OnceLock` is in `std`: @bushrat011899 what should we do here?~~
- Do you have ideas for more automated tests for this collection of
features?

## Benchmarks

I checked the impact of the feature flag introduced: benchmarks might
show regressions. This bears more investigation. I'm still skeptical
that there are users who are well-served by a fast always panicking
approach, but I'm going to re-add the feature flag here to avoid
stalling this out.


![image](https://github.com/user-attachments/assets/237f644a-b36d-4332-9b45-76fd5cbff4d0)

---------

Co-authored-by: Zachary Harrold <zac@harrold.com.au>
2025-03-18 19:27:50 +00:00
Antony
65e289f5bc
Unify picking backends (#17348)
# Objective

Currently, our picking backends are inconsistent:

- Mesh picking and sprite picking both have configurable opt in/out
behavior. UI picking does not.
- Sprite picking uses `SpritePickingCamera` and `Pickable` for control,
but mesh picking uses `RayCastPickable`.
- `MeshPickingPlugin` is not a part of `DefaultPlugins`.
`SpritePickingPlugin` and `UiPickingPlugin` are.

## Solution

- Add configurable opt in/out behavior to UI picking (defaults to opt
out).
- Replace `RayCastPickable` with `MeshPickingCamera` and `Pickable`.
- Remove `SpritePickingPlugin` and `UiPickingPlugin` from
`DefaultPlugins`.

## Testing

Ran some examples.

## Migration Guide

`UiPickingPlugin` and `SpritePickingPlugin` are no longer included in
`DefaultPlugins`. They must be explicitly added.

`RayCastPickable` has been replaced in favor of the `MeshPickingCamera`
and `Pickable` components. You should add them to cameras and entities,
respectively, if you have `MeshPickingSettings::require_markers` set to
`true`.

---------

Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
2025-03-18 19:24:43 +00:00
ickshonpe
b3ccc623fa
Remove commented-out code (#18392)
# Objective

Remove a leftover commented-out line.
2025-03-18 12:46:29 +00:00
Zachary Harrold
c9f37efeb7
Remove example causing circular dependency in bevy_platform_support (#18390)
# Objective

- Alternative to #18389

## Solution

- Remove improper example.

Co-authored-by: François Mockers <francois.mockers@vleue.com>
2025-03-18 08:58:52 +00:00
Fabian Thorand
205ae6441f
Force serial command encoding on Linux/amdvlk (#18368)
# Objective

Fixes https://github.com/bevyengine/bevy/issues/18366 which seems to
have a similar underlying cause than the already closed (but not fixed)
https://github.com/bevyengine/bevy/issues/16185.

## Solution

For Windows with the AMD vulkan driver, there was already a hack to
force serial command encoding, which prevented these issues. The Linux
version of the AMD vulkan driver seems to have similar issues than its
Windows counterpart, so I extended the hack to also cover AMD on Linux.

I also removed the mention of `wgpu` since it was already outdated, and
doesn't seem to be relevant to the core issue (the AMD driver being
buggy).

## Testing

- Did you test these changes? If so, how?
- I ran the `3d_scene` example, which on `main` produced the flickering
shadows on Linux with the amdvlk driver, while it no longer does with
the workaround applied.
- Are there any parts that need more testing?
  - Not sure.
- How can other people (reviewers) test your changes? Is there anything
specific they need to know?
  - Requires a Linux system with an AMD card and the AMDVLK driver.
- If relevant, what platforms did you test these changes on, and are
there any important ones you can't test?
  - My change should only affect Linux, where I did test it.
2025-03-18 03:16:38 +00:00
François Mockers
ce392fade8
remove circular dependency between bevy_sprite and bevy_image (#18379)
# Objective

- #17219 introduced a circular dependency between bevy_image and
bevy_sprite for documentation

## Solution

- Remove the circular dependency
- Simplify the doc example
2025-03-18 01:38:49 +00:00
Carter Anderson
6d6054116a
Support skipping Relationship on_replace hooks (#18378)
# Objective

Fixes #18357

## Solution

Generalize `RelationshipInsertHookMode` to `RelationshipHookMode`, wire
it up to on_replace execution, and use it in the
`Relationship::on_replace` hook.
2025-03-18 01:24:07 +00:00
François Mockers
ac53e4c482
only handle bin examples in showcase (#18374)
# Objective

- Some examples are now build as lib to be usable in other examples
since https://github.com/bevyengine/bevy/pull/18288
- Those examples are not correctly handled in the showcase as it tries
to run them

## Solution

- Ignore lib examples in showcase when taking screenshots or building
for the website
2025-03-18 00:52:42 +00:00
François Mockers
31d2b6539c
remove circular dependency between bevy_image and bevy_core_pipeline (#18377)
# Objective

- https://github.com/bevyengine/bevy/pull/17887 introduced a circular
dependency between bevy_image and bevy_core_pipeline
- This makes it impossible to publish Bevy

## Solution

- Remove the circular dependency, reintroduce the compilation failure
- This failure shouldn't be an issue for users of Bevy, only for users
of subcrates, and can be workaround
- Proper fix should be done with
https://github.com/bevyengine/bevy/issues/17891
- Limited compilation failure is better than publish failure
2025-03-18 00:52:31 +00:00
ickshonpe
4d8bc6161b
Extract sprites into a Vec (#17619)
# Objective

Extract sprites into a `Vec` instead of a `HashMap`.

## Solution

Extract UI nodes into a `Vec` instead of an `EntityHashMap`.
Add an index into the `Vec` to `Transparent2d`.
Compare both the index and render entity in prepare so there aren't any
collisions.

## Showcase
yellow this PR, red main

```
cargo run --example many_sprites --release --features "trace_tracy"
```

`extract_sprites`
<img width="452" alt="extract_sprites"
src="https://github.com/user-attachments/assets/66c60406-7c2b-4367-907d-4a71d3630296"
/>

`queue_sprites`
<img width="463" alt="queue_sprites"
src="https://github.com/user-attachments/assets/54b903bd-4137-4772-9f87-e10e1e050d69"
/>

---------

Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
2025-03-18 00:48:33 +00:00
Zachary Harrold
958c9bb652
Add no_std Library Example (#18333)
# Objective

- Fixes #17506
- Fixes #16258

## Solution

- Added a new folder of examples, `no_std`, similar to the `mobile`
folder.
- Added a single example, `no_std_library`, which demonstrates how to
make a `no_std` compatible Bevy library.
- Added a new CI task, `check-compiles-no-std-examples`, which checks
that `no_std` examples compile on `no_std` targets.
- Added `bevy_platform_support::prelude` to `bevy::prelude`.

## Testing

- CI

---

## Notes

- I've structured the folders here to permit further `no_std` examples
(e.g., GameBoy Games, ESP32 firmware, etc.), but I am starting with the
simplest and least controversial example.
- I've tried to be as clear as possible with the documentation for this
example, catering to an audience who may not have even heard of `no_std`
before.

---------

Co-authored-by: Greeble <166992735+greeble-dev@users.noreply.github.com>
2025-03-18 00:45:25 +00:00
Zachary Harrold
4fca331bb6
Fix Formatting of Optimisation Table (#18375)
# Objective

New markdown linter doesn't like this table.

## Solution

Fixed it.

## Testing

CI
2025-03-18 00:01:45 +00:00
krunchington
e5158ed96c
Update docs to explain default Hasher issue (#18350)
# Objective

I experienced an issue where `HashMap::new` was not returning a value
typed appropriately for a `HashMap<K,V>` declaration that omitted the
Hasher- e.g. the Default Hasher for the type is different than what the
`new` method produces.

After discussion on discord, this appears to be an issue in `hashbrown`,
and working around it would be very nontrivial, requiring a newtype on
top of the `hashbrown` implementation. Rather than doing that, it was
suggested that we add docs to make the issue more visible and provide a
clear workaround.

## Solution

Updated the docs for `bevy_platform_support::collections`. I couldn't
update Struct docs because they're re-exports, so I had to settle for
the module.

Note that the `[HashMap::new]` link wasn't generating properly- I'm not
sure why. I see the method in the docs.rs site,
https://docs.rs/hashbrown/0.15.1/hashbrown/struct.HashMap.html#method.new,
but not on the generated internal documentation. I wonder if `hashbrown`
isn't actually implementing the new or something?

## Testing

n/a although I did generate and open the docs on my Ubuntu machine.

---

## Showcase

before:

![image](https://github.com/user-attachments/assets/5c80417d-9c4e-4b57-825f-911203ed8558)

after:

![image](https://github.com/user-attachments/assets/420f6775-2f32-466f-a580-bb1344016bda)

---------

Co-authored-by: Zachary Harrold <zac@harrold.com.au>
2025-03-17 23:25:52 +00:00
charlotte
35bf9753e8
Fixes for WESL on Windows (#18373)
# Objective

WESL was broken on windows.

## Solution

- Upgrade to `wesl_rs` 1.2.
- Fix path handling on windows.
- Improve example for khronos demo this week.
2025-03-17 22:29:29 +00:00
François Mockers
4b457cc2ce
Revert "don't use bevy_pbr for base bevy_gizmos plugin" (#18327)
# Objective

- #17581 broke gizmos
- Fixes #18325

## Solution

- Revert #17581 
- Add gizmos to testbed

## Testing

- Run any example with gizmos, it renders correctly
2025-03-17 22:23:42 +00:00
ickshonpe
df1aa39ae4
Use UiRect::all to build the UiRect constants (#18372)
# Objective

Use the const `all` fn to create the UiRect consts instead of setting
the fields individually.
2025-03-17 21:51:11 +00:00
Mads Marquart
e6a6c9fb4c
Link iOS example with rustc, and avoid C trampoline (#14780)
# Objective

On iOS:
- Allow `std` to do its runtime initialization.
- Avoid requiring the user to specify linked libraries and framework in
Xcode.
- Reduce the amount of work that `#[bevy_main]` does
- In the future we may also be able to eliminate the need for it on
Android, cc @daxpedda.

## Solution

We previously:
- Exposed an `extern "C" fn main_rs` entry point.
- Ran Cargo in a separate Xcode target as an external build system.
- Imported that as a dependency of `bevy_mobile_example.app`.
- Compiled a trampoline C file with Xcode that called `main_rs`.
- Linked that via. Xcode.

All of this is unnecessary; `rustc` is well capable of creating iOS
executables, the trick is just to place it at the correct location for
Xcode to understand it, namely `$TARGET_BUILD_DIR/$EXECUTABLE_PATH`
(places it in `bevy_mobile_example.app/bevy_mobile_example`).

Note: We might want to wait with the changes to `#[bevy_main]` until the
problem is resolved on Android too, to make the migration easier.

## Testing

Open the Xcode project, and build for an iOS target.

---

## Migration Guide

**If you have been building your application for iOS:**

Previously, the `#[bevy_main]` attribute created a `main_rs` entry point
that most Xcode templates were using to run your Rust code from C. This
was found to be unnecessary, as you can simply let Rust build your
application as a binary, and run that directly.

You have two options for dealing with this:

If you've added further C code and Xcode customizations, or it makes
sense for your use-case to continue link with Xcode, you can revert to
the old behaviour by adding `#[no_mangle] extern "C" main_rs() { main()
}` to your `main.rs`. Note that the old approach of linking a static
library prevents the Rust standard library from doing runtime
initialization, so certain functionality provided by `std` might be
unavailable (stack overflow handlers, stdout/stderr flushing and other
such functionality provided by the initialization routines).

The other, preferred option is to remove your "compile" and "link" build
phases, and instead replace it with a "run script" phase that invokes
`cargo build --bin ...`, and moves the built binary to the Xcode path
`$TARGET_BUILD_DIR/$EXECUTABLE_PATH`. An example of how to do this can
be viewed at [INSERT LINK TO UPDATED EXAMPLE PROJECT].
To make the debugging experience in Xcode nicer after this, you might
also want to consider either enabling `panic = "abort"` or to set a
breakpoint on the `rust_panic` symbol.

---------

Co-authored-by: François Mockers <mockersf@gmail.com>
Co-authored-by: François Mockers <francois.mockers@vleue.com>
2025-03-17 21:14:07 +00:00
Gino Valente
49659700b9
bevy: Replace unnecessary tuple type registrations (#18369)
# Objective

As pointed out by @cart on
[Discord](https://discord.com/channels/691052431525675048/1002362493634629796/1351279139872571462),
we should be careful when using tuple shorthand to register types. Doing
so incurs some unnecessary penalties such as memory/compile/performance
cost to generate registrations for a tuple type that will never be used.

A better solution would be to create a custom lint for this, but for now
we can at least remove the existing usages of this pattern.

> [!note]
> This pattern of using tuples to register multiple types at once isn't
inherently bad. Users should feel free to use this pattern, knowing the
side effects it may have. What this problem really is about is using
this in _library_ code, where users of Bevy have no choice in whether a
tuple is unnecessarily registered in an internal plugin or not.

## Solution

Replace tuple registrations with single-type registrations.

Note that I left the tuple registrations in test code since I feel like
brevity is more important in those cases. But let me know if I should
change them or leave a comment above them!

## Testing

You can test locally by running:

```
cargo check --workspace --all-features
```
2025-03-17 20:20:17 +00:00
François Mockers
d4906ddad1
Revert "Transform Propagation Optimization: Static Subtree Marking (#18094)" (#18363)
# Objective

- Fixes #18255
- Transform propagation is broken in some cases

## Solution

- Revert #18093

Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
2025-03-17 20:01:29 +00:00
andristarr
2b21b6cc13
FilteredResource returns a Result instead of a simple Option (#18265)
# Objective
FilteredResource::get should return a Result instead of Option

Fixes #17480 

---

## Migration Guide

Users will need to handle the different return type on
FilteredResource::get, FilteredResource::get_id,
FilteredResource::get_mut as it is now a Result not an Option.
2025-03-17 18:54:13 +00:00