# Objective
- Use a single quad to render a TilemapChunk
- Add support for tile color and visibility
## Testing
- Tested using example -- there doesn't appear to be any visual tile
bleeding or rounding issues. Open to ideas on further testing
# Objective
Don't ignore default query filters for `EntityRef` or `EntityMut`.
Currently, `Query<EntityRef>` will include entities with a `Disabled`
component, even though queries like `Query<()>` or `Query<Entity>` would
not. This was noticed in
https://github.com/bevyengine/bevy/pull/19711#discussion_r2205981065.
## Solution
Change `Access::contains` to completely ignore read access and just look
at filters and archetypal access. Filters covers `With`, `Without`, `&`,
and `&mut`, while archetypal covers `Has` and `Allows`.
Note that `Option<&Disabled>` will no longer count as a use of
`Disabled`, though.
# Objective
Closes#18383
## Solution
Given the 2 votes (me and @komadori ) for making angle-weighted normals
the default, I went ahead and did so, moving the face-weighted
implementation to the new `Mesh::compute_face_weighted_normals` method.
I factored out the common code between both into
`Mesh::compute_custom_smooth_normals`, which I went ahead and made
public to make it easier for users to add any other weighting methods
they might come up with.
If any of these decisions are undesirable for any reason, please let me
know and I will gladly make modifications.
## Testing & Showcase
I made a demo that exaggerates the difference at
[Waridley/bevy_smooth_normals_comparison](https://github.com/Waridley/bevy_smooth_normals_comparison).
Screenshots included in the readme.
Another way it could be demonstrated is via scaling a mesh along its
normals, like for generating outline meshes with inverted faces. I'd be
willing to make a demo for that as well.
I also edited and renamed the `compute_smooth_normals` tests to use
face-weighted normals, and added a new test for angle-weighted ones
which validates that all normals of a unit cube have each component
equal to `(±1 / √3) ± f32::EPSILON`.
## Migration Guide
#16050 already did not mention a migration guide, and it is not even in
a stable release yet. If this lands in a 0.16 RC, updating from RC1
would probably not require any changes in the vast majority of cases,
anyway. If someone really needs face-weighted normals, they can switch
to `.compute_face_weighted_normals()` or
`.with_computed_face_weighted_normals()`. And if for some reason they
really liked the old count-weighted implementation from 0.15, there is
an example in the docs for `compute_custom_smooth_normals`.
# Objective
Fix#18546 by adding a variant to `MergeMeshError`, for incompatible
primitive topologies.
## Solution
Made `MergeMeshError` into an enum with two variants;
`IncompatibleVertexAttributes` and `IncompatiblePrimitiveTopology`.
Added an if statement in `Mesh::merge` to check if the
`primitive_topology` field of `self` matches `other`.
Also renamed `MergeMeshError` to `MeshMergeError` to align with the two
other `MeshSomethingError`'s.
## Testing
Didn't do any.
# Objective
The ECS code to do with Observers was recently refactored to use an
`EventKey` newtype. On reading through the PR, I was a bit confused that
sometimes a variable called `event` refers to an `Event` and sometimes
it refers to an `EventKey`. I think the code is clearer when `event`
refers to an `Event` and `event_key` refers to an `EventKey`.
## Solution
This PR renames some uses of `event` to `event_key`.
## Testing
- Did you test these changes? If so, how?
I ran `cargo run -p ci -- tests`
- 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?
No.
- If relevant, what platforms did you test these changes on, and are
there any important ones you can't test?
Probably not relevant, but MacOS.
---------
Co-authored-by: Steve Alexander <steve.alexander@priva.com>
# Objective
Improvement of the documentation for SystemParam derive section so that
it mentions how to use a Query<&SomeComponent> as a SystemParam for a
struct that should have #[derive(SystemParam)].
## Solution
Added the documentation
---
## Showcase
the previous documentation
```rust
Query<'w, 's, Entity>,
Res<'w, SomeResource>,
ResMut<'w, SomeOtherResource>,
Local<'s, u8>,
Commands<'w, 's>,
EventReader<'w, 's, SomeEvent>,
EventWriter<'w, SomeEvent>
```
the new documentation
```rust
Query<'w, 's, Entity>,
Query<'w, 's, &'static SomeComponent>, <================== the new thing
Res<'w, SomeResource>,
ResMut<'w, SomeOtherResource>,
Local<'s, u8>,
Commands<'w, 's>,
EventReader<'w, 's, SomeEvent>,
EventWriter<'w, SomeEvent>
```
# Objective
- Fixes#20008 - Preconvert colors before sending them to the UI
gradients shader for better performance
## Solution
- Modified `prepare_gradient` in `gradient.rs` to convert colors from
`LinearRgba` to `Srgba` on the CPU before sending to the GPU
- Updated the gradient shader to remove per-pixel color space
conversions since colors are now pre-converted
- Added documentation to clarify that vertex colors are in sRGB space
This optimization reduces the number of power operations per pixel from
3 to 1:
- **Before**: Convert start color to sRGB, convert end color to sRGB,
mix, convert back to linear (3 pow operations per pixel)
- **After**: Colors pre-converted on CPU, mix in sRGB space, convert
back to linear (1 pow operation per pixel)
## Testing
- Verified that the UI gradient examples (`cargo run --example
gradients`) compile and render correctly
- The visual output should remain identical while performance improves,
especially for large gradient areas
- Changes maintain the same color interpolation behavior (mixing in sRGB
space)
To test:
1. Run `cargo run --example gradients` or `cargo run --example
stacked_gradients`
2. Verify gradients render correctly
---------
Co-authored-by: ickshonpe <david.curthoys@googlemail.com>
# Objective
- Add an easy way to finish a Timer
## Solution
- Tick the timer by the remaining time
## Testing
I have not tested, but it should work
---
## Showcase
```rust
let mut timer = Timer::from_seconds(1.5, TimerMode::Once);
timer.finish();
assert_eq!(timer.remaining(), Duration::from_secs(0))
```
---------
Co-authored-by: Jan Hohenheim <jan@hohenheim.ch>
Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
# Objective
#### Goals
* Stop layout updates from overwriting `ScrollPosition`.
* Make `ScrollPosition` respect scale factor.
* Automatically allocate space for a scrollbar on an axis when
`OverflowAxis::Scroll` is set.
#### Non-Goals
* Overflow-auto support (I was certain Taffy had this already, but
apparently I was hallucinating).
* Implement any sort of scrollbar widgets.
* Stability (not needed because no overflow-auto support).
* Maybe in the future we could make a `ScrollbarWidth` enum to more
closely match the CSS API with its auto/narrow/none options. For now
`scrollbar_width` is just an `f32` which matches Taffy's API.
## Solution
* Layout updates no longer overwrite `ScrollPosition`'s value.
* Added the field `scrollbar_width: f32` to `Node`. This is sent to
`Taffy` which will automatically allocate space for scrollbars with this
width in the layout as needed.
* Added the fields `scrollbar_width: f32` and `scroll_position: Vec2` to
`ComputedNode`. These are updated automatically during layout.
* `ScrollPosition` now respects scale factor.
* `ScrollPosition` is no longer automatically added to every UI node
entity by `ui_layout_system`. If every node needs it, it should just be
required by (or be a field on) `Node`. Not sure if that's necessary or
not.
## Testing
For testing you can look at:
* The `scrollbars` example, which should work as before.
* The new example `drag_to_scroll`.
* The `scroll` example which automatically allocates space for
scrollbars on the left hand scrolling list. Did not implement actual
scrollbars so you'll just see a gap atm.
---------
Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
# Objective
Since we are planning to remove the need to derive both `Event` and
`EntityEvent` in 0.17 either way, I'm choosing to do the easy thing in
this PR so we can get the churn out of the way early.
Context from
[discord](https://discordapp.com/channels/691052431525675048/1383928409784193024/1393463673137401946).
Related to, and will conflict slightly with #20101.
## Solution
- Derive `Event` as part of the `EntityEvent` derive
- Remove any `Event` derives that were made unnecessary
- Update release notes
# Objective
- Progress towards #19887.
## Solution
- Convert `FromWorld` impls into systems.
- Run those systems in `RenderStartup`.
## Testing
- Ran `bloom_3d`, `auto_exposure`, `depth_of_field`, `motion_blur`,
`skybox`, `post_processing`, and `tonemapping` examples and they all
work :)
# Objective
- Progress towards #19887.
## Solution
- Convert FromWorld implementations into systems.
- Move any resource "manipulation" from `Plugin::finish` to systems.
- Add `after` dependencies to any uses of these resources (basically all
`SpritePipeline`).
## Testing
- Ran the `sprite`, and `mesh2d_manual` example and it worked.
# Objective
- Part of #20115
We want to encapsulate each part of `ScheduleGraph` into its own
specific struct to make parts of it easier to reuse and maintain.
## Solution
- Pulled `ScheduleGraph::systems` and `ScheduleGraph::system_conditions`
into a `Systems` struct and added a field for this new struct to
`ScheduleGraph`
- Broke up `ScheduleGraph::uninit` into `Systems::uninit` and
`SystemSets::uninit` to eliminate `ScheduleGraph`'s direct field access
of these types
- Removed node and condition accessors from `ScheduleGraph`; the same
operations are now available on `Systems` and `SystemSets` instead
(accessible via their `pub` fields on `ScheduleGraph`)
- Moved `Systems`, `SystemSets`, `SystemNode`, `SystemWithAccess`, and
`ConditionWithAccess` into a separate file.
## Testing
Added two new tests covering the API surface of `Systems` and
`SystemSets`, respectively.
---------
Co-authored-by: Chris Russell <8494645+chescock@users.noreply.github.com>
# Objective
- Improve usability of read-only systems.
## Solution
- Added `on_unimplemented` diagnostics for types/functions that aren't
read-only systems.
- Added `BoxedReadOnlySystem` type alias, similar to `BoxedSystem`.
## Testing
Can/should we test these diagnostics?
# Objective
Fix#18079
## Solution
- `EntityCloner` can now move components that don't have `Clone` or
`Reflect` implementation.
- Components with `ComponentCloneBehavior::Ignore` will not be moved.
- Components with `ComponentCloneBehavior::Custom` will be cloned using
their defined `ComponentCloneFn` and then removed from the source entity
to respect their `queue_deferred` logic.
- Relationships still need to be `Clone` or `Reflect` to be movable.
- Custom relationship data is now correctly preserved when cloned or
moved using `EntityCloner`.
## Testing
- Added new tests for moving components
---------
Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
# Objective
The names of the variants of `InterpolationColorSpace` don't match the
corresponding `Color` variants, which could be potentially confusing.
For instance, `Color` has an `Oklaba` variant, in
`InterpolationColorSpace` it's called `OkLab`.
## Solution
Rename variants of `InterpolationColorSpace` to mirror the variants of
Color.
# Objective
Fixes https://github.com/bevyengine/bevy/issues/19535. Improve
interoperability of type documentation to make it easier for users to
find related types
## Solution
- Add a reference to
[`ComponentIdFor`](crate::component::ComponentIdFor) in the
`component_id` function documentation in
`crates/bevy_ecs/src/world/mod.rs`
- Add a reference to [`ComponentIdFor`](super::ComponentIdFor) in the
`component_id` function documentation in
`crates/bevy_ecs/src/component/info.rs`
## Testing
- Verify documentation generation: `cargo doc`
- Check the validity of cross-reference links in the documentation
- Confirm that the documentation generated by rustdoc can correctly jump
to the type definition of `ComponentIdFor`
# Objective
Three impls are generated for each of these traits when the
`reflect_functions` feature is enabled.
Helps with #19873.
## Solution
Two of the three (the `&T` and `&mut T` ones) can be avoided by instead
providing blanket impls. The impl for `T` remains.
## Testing
I checked the output via `cargo expand`.
According to `-Zmacro-stats`, the size of the `Reflect` code generate
for `bevy_ui` drops by 10.4%.
# Objective
- Progress towards #19887.
- I am avoiding dealing with the `occlusion_culling` example since it is
kinda annoying to resolve nicely (I will do so in another PR).
## Solution
- Rewrite these examples to replace FromWorld implementations with
systems and other resource changes with systems as well.
## Testing
- All the changed examples have been tested and still work.
# Objective
- Clean up usage of BlitPipeline
## Solution
- add `create_bind_group` method
- adjust some field and variable names for clarity
## Testing
- ran 3d_scene
# Objective
Implement `Clone` for `IntoPipeSystem`, allowing for `T: IntoSystem +
Clone` patterns.
## Precedence
Same clone implementation/docs as `CombinatorSystem`
# Objective
> I think we should axe the shared `Event` trait entirely
It doesn't serve any functional purpose, and I don't think it's useful
pedagogically
@alice-i-cecile on discord
## Solution
- Remove `Event` as a supertrait of `BufferedEvent`
- Remove any `Event` derives that were made unnecessary
- Update release notes
---------
Co-authored-by: SpecificProtagonist <vincentjunge@posteo.net>
