In `bevy_mod_picking` events are driven by several interlocking state
machines, which read and write events, and share state in a few common
resources. When I merged theses state machines into one to make event
ordering work properly, I combined this state and hid it in a `Local`.
This PR exposes the state in a resource again. Also adds a simple little
API for it. Useful for adding debug UI.
# Objective
Exposes a means to create an asset directory (and its parent
directories). Wasn't sure whether we also wanted the variant to create
directories without the parent (i.e. `mkdir` instead of `mkdir -p`)?
Fixes https://github.com/bevyengine/bevy_editor_prototypes/issues/144
# Objective
- Bumps accesskit and accesskit_winit dependencies
## Solution
- Fixes several breaking API changes introduced in accesskit 0.23.
## Testing
- Tested with the ui example and seems to work comparably
# Objective
Closes#16221.
## Solution
- Make `Gamepad` fields public and remove delegates / getters.
- Move `impl Into` to `Axis` methods (delegates for `Axis` used `impl
Into` to allow passing both `GamepadAxis` and `GamepadButton`).
- Improve docs.
## Testing
- I run tests.
Not sure if the migration guide is needed, since it's a feature from RC,
but I wrote it just in case.
---
## Migration Guide
- `Gamepad` fields are now public.
- Instead of using `Gamepad` delegates like `Gamepad::just_pressed`,
call these methods directly on the fields.
---------
Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
# Objective
GlobalTransform's current methods make it unintuitive, long and clunky
to access just the rotation or just the scale.
## Solution
Dedicated just_rotation() and scale() methods to access just these
properties.
I'm not sure about the naming, I chose just_rotation() to show that try
to indicate there is a waste since it also computes the other fields.
## Testing
- Did you test these changes? If so, how?
I tried logging the methods with a rotating and scaling cube and the
values were correct.
- Are there any parts that need more testing?
My methods are based on existing bevy/glam methods so should be correct
from the getgo.
- How can other people (reviewers) test your changes? Is there anything
specific they need to know?
Probably the easiest is using the 3d_rotations example, adding scaling
to it and then logging the methods I added
---
## Showcase
```rust
fn log(gt_query: Query<&GlobalTransform>) {
for global_transform in gt_query().iter() {
println!("{} {}", global_transform.just_rotation(), global_transform.scale());
}
}
```
---------
Co-authored-by: Sigma-dev <antonin.programming@gmail.com>
Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
# Objective
- fix formatting issue in "mesh_view_binding.wgsl"
_note: As naga-oil preprocessor match the whole line when finding an
"#endif",
It's just for external formatting tool and consistency._
## Solution
Trivial change.
Add '//' before the closing comment of the "#endif"
# Objective
gpu based mesh uniform construction in the `GpuPreprocessNode` is
currently in `Core3d`. The node iterates all views and schedules the
uniform construction for each. so
- when there are multiple 3d cameras, it runs multiple times on each
view
- if a view wants to render meshes but doesn't use the `Core3d` graph,
the camera must run later than at least one `Core3d`-based camera (or
add the node to its own graph, duplicating the work)
- If views want to share mesh uniforms there is no way to avoid running
the preprocessing for every view
## Solution
- move the node to the top level of the rendergraph, before the camera
driver node
- make the `PreprocessBindGroup` `clone`able, and add a
`SkipGpuPreprocessing` component to allow opting out per view
# Objective
Currently, if we have two cameras with the same output texture, one with
`CameraOutputMode::Write` and one with `CameraOutputMode::Skip`, it is
possible for the `CameraOutputMode::Write` camera to be assigned alpha
blending (which is the fallback blending when multiple cameras write to
the same output texture), although it is the only camera writing to the
output texture. This may or may not happen every restart of the app,
because the camera iteration order in prepare_view_upscaling_pipelines
isn't consistent. Since this is random behaviour I consider this a bug
and didn't add a migration guide.
## Solution
In `prepare_view_upscaling_pipelines` make sure we don't consider
cameras with CameraOutputMode::Skip to be outputting something to the
output texture.
## Testing
I ran a few examples to make sure nothing obvious is broken. There is no
example using CameraOutputMode::Skip, so I only tested the change in my
own App where this was relevant, which however isn't public.
# Objective
Expand the `ui` example to show off more of the features and make it
more useful for debugging.
# Solution
Added some extra elements to the `ui` example demonstrating outlines,
border-radius, rotation, image sizing and image flipping.
## Showcase
<img width="961" alt="uiexample"
src="https://github.com/user-attachments/assets/fb0cfb57-9102-4c6c-bc8e-03d3fa6e0bf6">
# Objective
- Choose LOD based on normal simplification error in addition to
position error
- Update meshoptimizer to 0.22, which has a bunch of simplifier
improvements
## Testing
- Did you test these changes? If so, how?
- Visualize normals, and compare LOD changes before and after. Normals
no longer visibly change as the LOD cut changes.
- 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?
- Run the meshlet example in this PR and on main and move around to
change the LOD cut. Before running each example, in
meshlet_mesh_material.wgsl, replace `let color = vec3(rand_f(&rng),
rand_f(&rng), rand_f(&rng));` with `let color =
(vertex_output.world_normal + 1.0) / 2.0;`. Make sure to download the
appropriate bunny asset for each branch!
# Objective
1. UI texture slicing chops and scales an image to fit the size of a
node and isn't meant to place any constraints on the size of the node
itself, but because the required components changes required `ImageSize`
and `ContentSize` for nodes with `UiImage`, texture sliced nodes are
laid out using an `ImageMeasure`.
2. In 0.14 users could spawn a `(UiImage, NodeBundle)` which would
display an image stretched to fill the UI node's bounds ignoring the
image's instrinsic size. Now that `UiImage` requires `ContentSize`,
there's no option to display an image without its size placing
constrains on the UI layout (unless you force the `Node` to a fixed
size, but that's not a solution).
3. It's desirable that the `Sprite` and `UiImage` share similar APIs.
Fixes#16109
## Solution
* Remove the `Component` impl from `ImageScaleMode`.
* Add a `Stretch` variant to `ImageScaleMode`.
* Add a field `scale_mode: ImageScaleMode` to `Sprite`.
* Add a field `mode: UiImageMode` to `UiImage`.
* Add an enum `UiImageMode` similar to `ImageScaleMode` but with
additional UI specific variants.
* Remove the queries for `ImageScaleMode` from Sprite and UI extraction,
and refer to the new fields instead.
* Change `ui_layout_system` to update measure funcs on any change to
`ContentSize`s to enable manual clearing without removing the component.
* Don't add a measure unless `UiImageMode::Auto` is set in
`update_image_content_size_system`. Mutably deref the `Mut<ContentSize>`
if the `UiImage` is changed to force removal of any existing measure
func.
## Testing
Remove all the constraints from the ui_texture_slice example:
```rust
//! This example illustrates how to create buttons with their textures sliced
//! and kept in proportion instead of being stretched by the button dimensions
use bevy::{
color::palettes::css::{GOLD, ORANGE},
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())
.add_systems(Startup, setup)
.add_systems(Update, button_system)
.run();
}
fn button_system(
mut interaction_query: Query<
(&Interaction, &Children, &mut UiImage),
(Changed<Interaction>, With<Button>),
>,
mut text_query: Query<&mut Text>,
) {
for (interaction, children, mut image) in &mut interaction_query {
let mut text = text_query.get_mut(children[0]).unwrap();
match *interaction {
Interaction::Pressed => {
**text = "Press".to_string();
image.color = GOLD.into();
}
Interaction::Hovered => {
**text = "Hover".to_string();
image.color = ORANGE.into();
}
Interaction::None => {
**text = "Button".to_string();
image.color = Color::WHITE;
}
}
}
}
fn setup(mut commands: Commands, asset_server: Res<AssetServer>) {
let image = asset_server.load("textures/fantasy_ui_borders/panel-border-010.png");
let slicer = TextureSlicer {
border: BorderRect::square(22.0),
center_scale_mode: SliceScaleMode::Stretch,
sides_scale_mode: SliceScaleMode::Stretch,
max_corner_scale: 1.0,
};
// ui camera
commands.spawn(Camera2d);
commands
.spawn(Node {
width: Val::Percent(100.0),
height: Val::Percent(100.0),
align_items: AlignItems::Center,
justify_content: JustifyContent::Center,
..default()
})
.with_children(|parent| {
for [w, h] in [[150.0, 150.0], [300.0, 150.0], [150.0, 300.0]] {
parent
.spawn((
Button,
Node {
// width: Val::Px(w),
// height: Val::Px(h),
// horizontally center child text
justify_content: JustifyContent::Center,
// vertically center child text
align_items: AlignItems::Center,
margin: UiRect::all(Val::Px(20.0)),
..default()
},
UiImage::new(image.clone()),
ImageScaleMode::Sliced(slicer.clone()),
))
.with_children(|parent| {
// parent.spawn((
// 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)),
// ));
});
}
});
}
```
This should result in a blank window, since without any constraints the
texture slice image nodes should be zero-sized. But in main the image
nodes are given the size of the underlying unsliced source image
`textures/fantasy_ui_borders/panel-border-010.png`:
<img width="321" alt="slicing"
src="https://github.com/user-attachments/assets/cbd74c9c-14cd-4b4d-93c6-7c0152bb05ee">
For this PR need to change the lines:
```
UiImage::new(image.clone()),
ImageScaleMode::Sliced(slicer.clone()),
```
to
```
UiImage::new(image.clone()).with_mode(UiImageMode::Sliced(slicer.clone()),
```
and then nothing should be rendered, as desired.
---------
Co-authored-by: Carter Anderson <mcanders1@gmail.com>
# Objective
The schedule graph can easily confirm whether a set is contained or not.
This helps me in my personal project where I write an extension trait
for `Schedule` and I want to configure a specific set in its methods.
The set in question has a run condition though and I don't want to add
that condition to the same schedule as many times as the trait methods
are called. Since the non-pub set is unknown to the schedule until then,
a `contains_set` is sufficient.
It is probably trivial to add a method that returns an `Option<NodeId>`
as well but as I personally don't need it I did not add that. If it is
desired I can do so here though. It might be unneeded to have a
`contains_set` then because one could check `is_some` on the returned id
in that case.
An argument against that is that future changes may be easier if only a
`contains_set` needs to be ported.
## Solution
Added `ScheduleGraph::contains_set`.
## Testing
I put the below showcase code into a temporary unit test and it worked.
If wanted I add it as a test too but I did not see that other more
somewhat complicated methods have tests
---
## Showcase
```rs
#[derive(ScheduleLabel, Debug, Default, Clone, Copy, PartialEq, Eq, Hash)]
struct MySchedule;
#[derive(SystemSet, Debug, Default, Clone, Copy, PartialEq, Eq, Hash)]
struct MySet;
let mut schedule = Schedule::new(MySchedule);
assert_eq!(schedule.graph().contains_set(MySet), false);
schedule.configure_sets(MySet);
assert_eq!(schedule.graph().contains_set(MySet), true);
```
# Objective
- `CircularSegment` and `CircularSector` are well defined 2D shapes with
both an area and a perimeter.
# Solution
- This PR implements `perimeter` for both and moves the existsing `area`
functions into the `Measured2d` implementations.
## Testing
- The `arc_tests` have been extended to also check for perimeters.
# Objective
Currently there's no way to change the window's cursor icon with the
`custom_cursor` feature **disabled**. You should still be able to set
system cursor icons.
Connections:
- https://github.com/bevyengine/bevy/pull/15649
## Solution
Move some `custom_cursor` feature gates around, as to expose the
`CursorIcon` type again.
Note this refactoring was mainly piloted by hunting after the compiler
warnings -- I shouldn't have missed anything, but FYI.
## Testing
Disabled the `custom_cursor` feature, ran the `window_settings` example.
# Objective
clean up example get_single method, make code clean;
## Solution
- replace `Query` with `Single` Query
- remove `get_single` or `get_single_mut` condition block
# Objective
#14273 changed `Msaa` to be a component rather than a resource. However,
the documentation still says that it is a resource. This tripped me up
during migration to 0.15 until I looked at the type definition.
Additionally, the docs have some unnecessary repetition and some grammar
mistakes, and they don't link to camera documentation.
## Solution
Fix up the docs!
# Objective
When merging two meshes, we need to find the offset of indices for the
second mesh. Currently it is done by inserting empty positions if
positions is not set.
Although practically it is not an issue, this does not feel right:
- We did not have positions before, then why we have positions after
merge?
- Moreover, if positions are not set, but uvs are not empty, computed
offset will be zero, while it should be equal to the number of uvs.
## Solution
Use `Mesh::count_vertices` to find the number of vertices.
## Testing
Looking hard.
# Objective
There's integer overflow in `Mesh::merge` in branches like this:
405fa3e8ea/crates/bevy_mesh/src/mesh.rs (L857-L859)
we truncate `u32` to `u16` and ignore integer overflow on `u16`. This
may lead to unexpected results when the number of vertices exceeds
`u16::MAX`.
## Solution
Convert indices storage to `u32` when necessary.
## Testing
- Unit test added for `extend` function
- For changes in `Mesh`, I presume it is already tested elsewhere
# Objective
- Fixes#15757
## Solution
- Add the platform specific property `prefers_home_indicator_hidden` to
bevy's Window configuration, and applying it by invoking
`with_prefers_home_indicator_hidden` in `winit`.
## Testing
- I have tested the `bevy_mobile_example` on the iOS platform.
## Showcase
- Currently, the `prefers_home_indicator_hidden` is enabled in the
bevy_mobile_example demo. You can test it with an iOS device. The home
indicator will disappear after several seconds of inactivity in the
bottom areas.
---------
Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
# Objective
- Cleanup pass to make the examples a bit more succinct, focusing on the
topic at hand.
- Added drag rotation to make the picking examples more interesting, and
to demonstrate a simple use case.
# Objective
In the animation example, there is the code `.add_systems(Update,
init_animations.before(animate_targets))`, where `animate_targets` is
added to the `PostUpdate` in the `AnimationPlugin`. Therefore, the
`.before(animate_targets)` here is ineffective and should be removed.
# Objective
Fix#15841
## Solution
Added an update schedule as recommended in the issue.
## Testing
Doc test is run and passes.
Ran the example in a test app before and after adding the line.
## Showcase
Before:
```
PS C:\Users\BenjaminBrienen\source\bevy_experiment_test> cargo run
Blocking waiting for file lock on build directory
Compiling bevy_experiment_test v0.1.0 (C:\Users\BenjaminBrienen\source\bevy_experiment_test)
Finished `dev` profile [unoptimized + debuginfo] target(s) in 1m 41s
Running `target\debug\bevy_experiment_test.exe`
```
(nothing happens)
After:
```
PS C:\Users\BenjaminBrienen\source\bevy_experiment_test> cargo run
Blocking waiting for file lock on build directory
Compiling bevy_experiment_test v0.1.0 (C:\Users\BenjaminBrienen\source\bevy_experiment_test)
Finished `dev` profile [unoptimized + debuginfo] target(s) in 14.64s
Running `target\debug\bevy_experiment_test.exe`
system of subapp is executing and the Counter: 10
```
Fixes a small divergence between `bevy_mod_picking` and the up-streamed
`bevy_picking`: Both have a `Pointer<E>` constructor with the same
types, but in a different order.
This is part of work being done on `bevy_mod_picking` to simplify the
migration to `bevy_picking`.
# Objective
Make all the methods and associated functions belonging to
`ComputedNode` const.
## Solution
Constify (except for `inner_radius` which uses non-const `min` and
`max`).
---------
Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
# Objective
Fixes#15676
## Solution
`remove` returns the removed item
Add `take`
## Testing
None yet
## Migration Guide
If you don't need the returned value from `remove`, discard it.
# Objective
The `ContentSize` requirement on `UiImage` got lost during merge
conflict fixes, causing some images such as the icons on the `game_menu`
example to disappear.
Fixes#16136
## Solution
Require `ContentSize` on `UiImage` again.
---------
Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
# Objective
Taffy added layout rounding a while ago but it had a couple of bugs and
caused some problems with the fussy `ab_glyph` text implementation. So I
disabled Taffy's builtin rounding and added some hacks ad hoc that fixed
(some) of those issues. Since then though Taffy's rounding algorithm has
improved while we've changed layout a lot and migrated to `cosmic-text`
so those hacks don't help any more and in some cases cause significant
problems.
Also our rounding implementation only rounds to the nearest logical
pixel, whereas Taffy rounds to the nearest physical pixel meaning it's
much more accurate with high dpi displays.
fixes#15197
## Some examples of layout rounding errors visible in the UI examples
These errors are much more obvious at high scale factor, you might not
see any problems at a scale factor of 1.
`cargo run --example text_wrap_debug`
<img width="1000" alt="text_debug_gaps"
src="https://github.com/user-attachments/assets/5a584016-b8e2-487b-8842-f0f359077391">
The narrow horizontal and vertical lines are gaps in the layout caused
by errors in the coordinate rounding.
`cargo run --example text_debug`
<img width="1000" alt="text_debug"
src="https://github.com/user-attachments/assets/a4b37c02-a2fd-441c-a7bd-cd7a1a72e7dd">
The two text blocks here are aligned right to the same boundary but in
this screen shot you can see that the lower block is one pixel off to
the left. Because the size of this text node changes between frames with
the reported framerate the rounding errors cause it to jump left and
right.
## Solution
Remove all our custom rounding hacks and reenable Taffy's layout
rounding.
The gaps in the `text_wrap_debug` example are gone:
<img width="1000" alt="text_wrap_debug_fix"
src="https://github.com/user-attachments/assets/92d2dd97-30c6-4ac8-99f1-6d65358995a7">
This doesn't fix some of the gaps that occur between borders and content
but they seem appear to be a rendering problem as they disappear with
`UiAntiAlias::Off` set.
## Testing
Run the examples as described above in the `Objective` section. With
this PR the problems mentioned shouldn't appear.
Also added an example in a separate PR #16096 `layout_rounding_debug`
for identifying these issues.
## Migration Guide
`UiSurface::get_layout` now also returns the final sizes before
rounding. Call `.0` on the `Ok` result to get the previously returned
`taffy::Layout` value.
---------
Co-authored-by: Rob Parrett <robparrett@gmail.com>
# Objective
- Fixes#16122
When the wayland feature is not enabled, xwayland is used on wayland.
Nvidia drivers are somewhat bugged on linux and return outdated surfaces
on xwayland for seemingly no reason. Oftentimes at startup we get into
an infine loop where the surface is permanently outdated and nothing (or
sometimes only the first frame) is drawn on the screen.
## Solution
After experimenting I found that we can safely call configure again and
the issue seems to resolve itsef. After this change I couldn't reproduce
the original issue after many tries. More testing is probably needed
though.
The main issue is that `get_current_texture` fails sometimes because the
surface remains outdated even after configuring. It would be better to
just properly handle and never panic when `get_current_texture` fails.
This way we always call configure when outdated and bail when getting
the swapchain fails instead of crashing. The number of special cases is
also reduced.
## Testing
I tested the example "rotation" manually by trying to move around.
It works with X11 and Xwayland and the non panicing code paths didn't
change so other platforms aren't affected.
# Objective
- Display message for `AsBindGroupError::InvalidSamplerType` was not
correctly displaying the binding index
## Solution
- Simple typo fix
## Testing
- Tested locally
# Objective
The `headless_renderer` example is meant to showcase running bevy as a
headless renderer, but if run without a display server (for example,
over an SSH connection), a panic occurs in `bevy_winit` despite never
creating a window:
```rust
bevy_winit-0.14.1/src/lib.rs:132:14:
winit-0.30.5/src/platform_impl/linux/mod.rs:
neither WAYLAND_DISPLAY nor WAYLAND_SOCKET nor DISPLAY is set.
```
This example should run successfully in situations without an available
display server, as although the GPU is used for rendering, no window is
ever created.
## Solution
Disabling WinitPlugin, where the above panic occurs, allows the example
to run in a fully headless environment.
## Testing
- I tested this change in normal circumstances with a display server (on
macOS Sequoia and Asahi Linux) and behavior was normal.
- I tested with no display server by connecting via SSH, and running the
example (on Asahi Linux). Previously this panics, but with this change
it runs normally.
## Considerations
- One could argue that ultimately the user should not need to remove
`WinitPlugin`, and instead bevy should only throw the above panic when
the application first attempts to create a window.
## Methodology
A good metric that correlates with compile time is the amount of code
generated by the compiler itself; even if the end binary is exactly the
same size, having more copies of the same code can really slow down
compile time, since it has to figure out whether it needs to include
them or not.
The measurement for this used was the [`cargo-llvm-lines`
crate](https://docs.rs/crate/cargo-llvm-lines) which can measure which
functions are generating the most lines of LLVM IR, which generally
means more code compiled. The example compiled was the `breakout` game,
to choose something that touches a decent portion of the engine.
## Solution
Based upon the measurements, `bevy_ptr::OwnedPtr::make` was taking up
4061 lines of LLVM IR in the example code. So, I separated part of this
function into a less-monomorphised version to reduce the amount of
generated code. This was by far the most lines emitted by any single
function.
## Results
After this change, only 2560 lines are emitted, accounting for a 36%
decrease. I tried timing the results and it seemed like it did decrease
compile times a bit, but honestly, the data is really noisy and I can't
be bothered to compile bevy for hours on end to get enough data points.
The tweak feels like an improvement, so, I'll offer it, however small.
# Objective
Remove `calculated_` from the name `ComputedNode::calculated_size` as
redundant, It's obvious from context that it's the resolved size value
and it's inconsistant since none of other fields of `ComputedNode` have
a `calculated_` prefix.
## Alternatives
Rename all the fields of `ComputedNode` to `calculated_*`, this seems
worse.
Bumps [crate-ci/typos](https://github.com/crate-ci/typos) from 1.26.0 to
1.26.8.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/crate-ci/typos/releases">crate-ci/typos's
releases</a>.</em></p>
<blockquote>
<h2>v1.26.8</h2>
<h2>[1.26.8] - 2024-10-24</h2>
<h2>v1.26.3</h2>
<h2>[1.26.3] - 2024-10-24</h2>
<h3>Fixes</h3>
<ul>
<li>Accept <code>additionals</code></li>
</ul>
<h2>v1.26.2</h2>
<h2>[1.26.2] - 2024-10-24</h2>
<h3>Fixes</h3>
<ul>
<li>Accept <code>tesselate</code> variants</li>
</ul>
<h2>v1.26.1</h2>
<h2>[1.26.1] - 2024-10-23</h2>
<h3>Fixes</h3>
<ul>
<li>Respect <code>--force-exclude</code> for binary files</li>
</ul>
</blockquote>
</details>
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a
href="https://github.com/crate-ci/typos/blob/master/CHANGELOG.md">crate-ci/typos's
changelog</a>.</em></p>
<blockquote>
<h2>[1.26.8] - 2024-10-24</h2>
<h2>[1.26.7] - 2024-10-24</h2>
<h2>[1.26.6] - 2024-10-24</h2>
<h2>[1.26.5] - 2024-10-24</h2>
<h2>[1.26.4] - 2024-10-24</h2>
<h2>[1.26.3] - 2024-10-24</h2>
<h3>Fixes</h3>
<ul>
<li>Accept <code>additionals</code></li>
</ul>
<h2>[1.26.2] - 2024-10-24</h2>
<h3>Fixes</h3>
<ul>
<li>Accept <code>tesselate</code> variants</li>
</ul>
<h2>[1.26.1] - 2024-10-23</h2>
<h3>Fixes</h3>
<ul>
<li>Respect <code>--force-exclude</code> for binary files</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a
href="0d9e0c2c1b"><code>0d9e0c2</code></a>
chore: Release</li>
<li><a
href="e5385b07a0"><code>e5385b0</code></a>
chore(ci): Fix new release process</li>
<li><a
href="f08d1171e2"><code>f08d117</code></a>
chore: Release</li>
<li><a
href="e6e172498c"><code>e6e1724</code></a>
chore(ci): Fix new release process</li>
<li><a
href="02afc59fd4"><code>02afc59</code></a>
chore: Release</li>
<li><a
href="f981a1cd20"><code>f981a1c</code></a>
chore(ci): Fix new release process</li>
<li><a
href="afbc96c5d3"><code>afbc96c</code></a>
chore: Release</li>
<li><a
href="d3dcaaeb2d"><code>d3dcaae</code></a>
chore(ci): Fix new release process</li>
<li><a
href="fb8217bd5e"><code>fb8217b</code></a>
chore: Release</li>
<li><a
href="88ea8ea67d"><code>88ea8ea</code></a>
chore(ci): Stage releases until done</li>
<li>Additional commits viewable in <a
href="https://github.com/crate-ci/typos/compare/v1.26.0...v1.26.8">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
# Objective
Make the following functions `const` that will be useful to define
colors as constants.
- `Color::srgb_from_array`
- `Color::srgba_u8`
- `Color::srgb_u8`
The last two require Rust 1.82.0.
## Solution
- Make them `const`
- Change MSRV to 1.82.0
## Testing
I tested bevy_color only. My machine does not have enough RAM capacity
to test the whole bevy.
`cargo test -p bevy_color`
# Objective
Missed this in the required components PR review. `ContentSize` isn't
used by regular UI nodes, only those with intrinsically sized content
that needs a measure func.
## Solution
Remove `ContentSize` from `Node`'s required components and add it to the
required components of `Text` and `UiImage`.
---------
Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
# Objective
`UiImage` isn't just a general image component now, it's the defining
component for the image widget so it belongs in the image widget's
module.
# Objective
Order independent transparency can filter fragment writes based on the
alpha value and it is currently hard-coded to anything higher than 0.0.
By making that value configurable, users can optimize fragment writes,
potentially reducing the number of layers needed and improving
performance in favor of some transparency quality.
## Solution
This PR adds `alpha_threshold` to the
OrderIndependentTransparencySettings component and uses the struct to
configure a corresponding shader uniform. This uniform is then used
instead of the hard-coded value.
To configure OIT with a custom alpha threshold, use:
```rust
fn setup(mut commands: Commands) {
commands.spawn((
Camera3d::default(),
OrderIndependentTransparencySettings {
layer_count: 8,
alpha_threshold: 0.2,
},
));
}
```
## Testing
I tested this change using the included OIT example, as well as with two
additional projects.
## Migration Guide
If you previously explicitly initialized
OrderIndependentTransparencySettings with your own `layer_count`, you
will now have to add either a `..default()` statement or an explicit
`alpha_threshold` value:
```rust
fn setup(mut commands: Commands) {
commands.spawn((
Camera3d::default(),
OrderIndependentTransparencySettings {
layer_count: 16,
..default()
},
));
}
```
---------
Co-authored-by: JMS55 <47158642+JMS55@users.noreply.github.com>
# Objective
This example is really confusing to look at and tell at a glance whether
it's broken or not.
It's displaying a strange shape -- a cube with two vertices stretched in
a couple dimensions at an odd angle, and doing its vertex position
modification in a way where the intent isn't obvious.
## Solution
- Change the gltf geometry so that the object is a recognizable regular
shape
- Change the vertex modification so that the entire cube top is being
"lifted" from the cube
- Adjust colors, lighting, and camera location so we can see what's
going on
- Also remove some irrelevant shadow and environment map setup
## Before
## After
<img width="1280" alt="image"
src="https://github.com/user-attachments/assets/59cab60d-efbc-47c3-8688-e4544b462421">
# Objective
In `bevy_mod_picking` events are accessible through event listeners or
`EventReader`s. When I replaced event listeners with observers, I
removed the `EventReader` for simplicity. This adds it back.
## Solution
All picking events are now properly registered, and can be accessed
through `EventReader<Pointer<E>>`. `Pointer` now tracks the entity the
event targeted initially, and this can also be helpful in observers
(which don't currently do this).
## Testing
The picking examples run fine. This shouldn't really change anything.
---------
Co-authored-by: Aevyrie <aevyrie@gmail.com>
# Objective
- Mesh picking is noisy when a non triangle list is used
- Mesh picking runs even when users don't need it
- Resolve#16065
## Solution
- Don't add the mesh picking plugin by default
- Remove error spam
