Render api2 by jasmine-nominal · Pull Request #41 · JMS55/bevy

jasmine-nominal · 2025-10-31T17:49:58Z

No description provided.

…tion` (bevyengine#21577) # Objective Fixes bevyengine#14309 ## Solution Renamed the `bevy_reflect` feature from `documentation` to `reflect_documentation` to follow the naming convention where features are prefixed with their module name. ## Changes - Renamed feature `documentation` to `reflect_documentation` in: - `bevy_reflect/Cargo.toml` - `bevy_reflect/derive/Cargo.toml` - `bevy_internal/Cargo.toml` - Updated all conditional compilation attributes from `#[cfg(feature = "documentation")]` to `#[cfg(feature = "reflect_documentation")]` - Updated example documentation in `reflect_docs.rs` ## Testing <img width="1414" height="688" alt="截图 2025-10-17 18-52-14" src="https://github.com/user-attachments/assets/461d827a-c958-4c0d-862d-aae25598f2f7" />

## Objective While tinkering with change detection, I've collected some nitpicks: - The word "ticks" is kind of overloaded; ticks are used by components, systems, and the world, but "ticks" is often used to refer to the "added + changed" pair of ticks that only components have (and resources, but they're close enough to components). - `Ticks` is a nice name for a struct, but it's taken by a `pub(crate)` struct that's pretty niche. (I don't have any plans for the `Ticks` name, but it could be useful for something.) - Every use of `Ticks`, `TicksMut`, and `TickCells` is accompanied by a `MaybeLocation` that represents the calling location that last modified the component, so it should just be part of the structs. - `NonSend` seems to be in the wrong file, and doesn't implement methods with the macros that every other change-detecting query parameter uses. ## Solution Renamed the following structs: - `Ticks` -> `RefComponentTicks` - `TicksMut` -> `MutComponentTicks` - `TickCells` -> `ComponentTickCells` Added a `changed_by: MaybeLocation` field to `RefComponentTicks`, `MutComponentTicks`, and `ComponentTickCells` and folded in the loose `MaybeLocation`s. Moved `NonSend` from `system/system_param.rs` to `change_detection.rs` and updated its implementation to match similar query parameters. Removed `ComponentTickCells::read` because it is now unused (and not public).

# Objective - Fixes bevyengine#16654 ## Solution - Updated the doc string and linked to TemporaryRenderEntity. ## Testing - Built the documentation locally and verified that the links render and navigate correctly.

…`bevy` main crate to be more accurate (bevyengine#21590) # Objective The `bevy` main crate's `lib.rs` file contains an expectation for the `clippy::doc_markdown` lint. However, it only references one of the many times that `clippy::doc_markdown` lints on that file. Many of the other `clippy::doc_markdown` instances are within the cargo features list. ## Solution Rewrite the reason for this expectation to be more clear. Additionally, mark `GameActivity` as an allowed doc ident for Clippy. ## Testing `cargo clippy` returned no errors.

# Objective Multiple tests derive both `Resource` and `Component` on a single struct. In the current resources-for-components plan (bevyengine#19731), this leads to a conflict. ## Solution ```rust #[derive(Resource, Component)] struct A; ``` Becomes ```rust #[derive(Component)] struct A; #[derive(Resource)] struct ResA; ``` and the tests are changed accordingly. There was one test that had to be removed as it specifically tested that a query could both query a resource and a component with the same name. That test doesn't make any sense anymore, so I removed it. ## Testing I tested the changes by adding code into `Resource` derive macro, that also derives `Component`, so any conflicts showed up by running `cargo build`. ## Future work `AmbientLight` in `bevy_light` still derives both, but since that requires a little more work, I'm saving it for later.

…misleading docs surrounding it (bevyengine#21593) # Objective - The current name and docs tell you this is the animation player entity. But it's not necessarily! When adding an event via `AnimationClip::add_event_to_target`, that entity actually points to the `AnimationTargetId`, not the animation player! - This just caused some major confusion for me while debugging a system that was supposed to play a sound effect from a specific bone (namely a footstep from the foot). ## Solution - Rename the field to `target` - Change the docs to mention the nuance ## Testing - Verified behavior in a test scene

…ngine#21605) # Objective `world/entity_ref.rs` is the biggest single source file in Bevy at ~6800 lines. It can be a bit hard to navigate. ## Solution Rename the `entity_ref` module to `entity_access` and split it into 8 files: - `mod.rs`: Re-exports and testing, ~1600 lines - `entity_ref.rs`: `EntityRef` type, ~340 lines - `entity_mut.rs`: `EntityMut` type, ~760 lines - `world_mut.rs`: `EntityWorldMut` type, ~2200 lines - `filtered.rs`: `FilteredEntityRef` and `FilteredEntityMut` types, ~780 lines - `except.rs`: `EntityRefExcept` and `EntityMutExcept` types, ~500 lines - `entry.rs`: `ComponentEntry` type, ~330 lines - `component_fetch.rs`: `DynamicComponentFetch` trait, ~360 lines `world_mut` is still sizable, but that's just the sheer number of methods `EntityWorldMut` has. Splitting the methods across multiple files is possible, but that might be more annoying than a large file.

…evyengine#21604) ## Objective `change_detection.rs` is a bit big at ~1900 lines and its contents are pretty varied, so it ought to be split up. ## Solution Split `change_detection.rs` into 4 files: - `mod.rs`: Re-exports, some constants, testing - `params.rs`: Change-detecting system/query parameters like `Ref` and `Res` - `traits.rs`: The `DetectChanges` and `DetectChangesMut` traits and the macros used internally to implement those traits (and some others) for the above parameters - `maybe_location.rs`: `MaybeLocation` and its impls This shouldn't change anything publicly, since everything's still in the same module. I'd also like to move `component/tick.rs` into this module, but that would break stuff, so that'll be its own PR.

@BD103

# Objective bevyengine/bevy-website#2293 proposed a rename of our `M-Needs-Release-Note` and `M-Needs-Migration-Guide` labels for improved clarity. This has been approved, so I'm merging that PR. This repo lists these labels in a few places for automation / contributor help, and they need to be updated. ## Solution Grep for these like @BD103 told me to in bevyengine/bevy-website#2293 (comment) ## Follow-up work Once this PR is merged I'll actually rename the label.

…1571) # Objective Fixes bevyengine#16809 ## Solution - Correct NDC coordinate ranges and depth interpretation - Fix method reference from world_to_viewport to viewport_to_world - Update parameter name in error condition from world_position to ndc_point - Clarify that returned world position is not limited to NDC

…1592) # Objective This PR fixes bevyengine#21569, which proposes renaming the newly introduced camera controller modules `FreeCam` and `PanCam` to use the full term `Camera`. ## Solution * Renamed the `PanCam` controller, `PanCamPlugin`, and related methods to use the full term `Camera` instead of the abbreviation `Cam`. * Renamed the module from `pan_cam` to `pan_camera` for consistency with naming conventions. * Updated the example `pan_camera_controller` and adjusted usage of the renamed controller and plugin. * Updated documentation and release notes accordingly. ## Follow-up Work I see two options from here: 1. **Use this PR as a reference** for renaming `FreeCam`. The process is similar and could be a great first issue for someone looking to contribute to the new camera modules or Bevy in general. Most of the changes follow the same pattern, although `FreeCam` has more examples that need updating. One could find them using `grep` (e.g., `grep FreeCam`) or by reviewing the diff from the PR that introduced `FreeCam`: bevyengine#20215 2. **I can continue and update this PR** to also handle the `FreeCam` renaming, if you'd prefer to resolve the entire issue in one go. --------- Co-authored-by: syszery <syszery@users.noreply.github.com>

…ic contexts (bevyengine#21601) # Objective Currently there is no way to traverse relationships in type-erased contexts or to define dynamic relationship components, which is a hole in the current relationships api. ## Solution Introduce `RelationshipAccessor` to describe a way to get `Entity` values from any registered relationships in dynamic contexts and store it on `ComponentDescriptor`. This allows to traverse relationships without knowing their type, which is useful for working with entity hierarchies using non-default components. ## Testing Added a simple test/example of how to use this api to traverse hierarchies in a type-erased context.

…evyengine#21608) # Objective - Part of bevyengine#20115 - Since bevyengine#20256, `ScheduleGraph::topsort_graph` no longer uses `self`, so let's put it directly on `DiGraph`. ## Solution - Moved `ScheduleGraph::topsort_graph` to `DiGraph::toposort`. - Added `DiGraphToposortError` with `Loop` and `Cycle` variants, which is wrapped to replace `ScheduleBuildError::HierarchyLoop`, `HierarchyCycle`, `DependencyLoop`, and `DependencyCycle`. - Added `ScheduleBuildError::FlatDependencySort` variant to detect issues specifically with the flattened dependency graph. - Removed `ReportCycles`: `DiGraph::toposort` returns an error that should be wrapped at the callsite, negating the need for this type. - Moved `simple_cycles_in_component` onto `DiGraph` (formerly a free-floating function). ## Testing Updated and reused current tests.

Follow-up to bevyengine#21604. `Tick` and friends should be in the `change_detection` module, not `component`.

…ters (bevyengine#21616) # Objective - Fixes bevyengine#21579 - Fixes bevyengine#20167 ## Solution - Allow at least the engine-internal default filters until we have bevyengine#21615 ## Testing - None. I think this is trivial enough.

…#21611) # Objective As discussed in bevyengine#19285, Bevy has reused the same conceptual names for multiple types across different crates, creating confusion for autocomplete tooling and users. This PR addresses one of those conflicts by removing the `ron` re-export from `bevy_scene` and `bevy_asset` ## Solution - Removed `pub use bevy_asset::ron;` from `bevy_scene::lib` and `pub use ron;` from `bevy_asset::lib` - Updated `crates/bevy_scene/Cargo.toml` - Updated all internal references to use `ron` directly: - `crates/bevy_scene/src/dynamic_scene.rs` - `crates/bevy_scene/src/scene_loader.rs` - `crates/bevy_scene/src/serde.rs` (including doc examples and tests) ## Testing - `cargo check --workspace` - all checks pass - `cargo test -p bevy_scene` - tests pass (4 pre-existing test failures unrelated to this change) - `cargo test -p bevy_asset` - tests pass - `cargo clippy` - no new warnings

# Objective - dont re-export SamplerBindingType twice for no reason ## Solution - dont re-export SamplerBindingType twice for no reason ## Testing - ci

# Objective - Address [this comment](bevyengine#21566 (comment)). ## Solution - Move all the asset processor tests into their own file. ## Testing - Ran the tests in single threaded and multi threaded mode.

# Objective For resources-as-components (bevyengine#19731), structs mustn't doubly derive both `Component` and `Resource`. ## Solution Split `AmbientLight` in two: `AmbientLight` (the resource) and `AmbientLightOverride` (the component). ## Testing I initially made two structs `AmbientLightComponent` and `AmbientLightResource`, and replaced every mention with the relevant one to ensure that I didn't confuse the two. ## Notes - I don't know if the names are correct. I kept the easiest name for the resource, as that's the one most often used. - I haven't provided any conversion methods as there are already plans to replace the component variant with something else. --------- Co-authored-by: atlv <email@atlasdostal.com>

# Objective Add minimal strikethrough support for text. ## Solution * Insert the new `Strikethrough` component on any `Text`, `Text2d`, or `TextSpan` entity and its text will be drawn with strikethrough. * The strikethrough geometry is stored in `TextLayoutInfo` in the vec with the section bounding rects. * Rendering is trivial, identical to drawing text background colours except it's a narrower rect drawn in front instead of behind. * Text shadows also have strikethrough if the text does. # This implementation can easily be expanded to support underline, I've already made a follow up PR that does this here: bevyengine#21559. ## Testing ``` cargo run --example strikethrough ``` ## Showcase <img width="1422" height="924" alt="strikeout" src="https://github.com/user-attachments/assets/c8ea2578-e40c-4c46-ae0d-df9e3f261f3a" />

at some point, the things it was pointing to were moved from bevy/sprite to bevy/prelude, so fix the link to point there

@cart

# Objective Despite initially advocating for its inclusion in bevyengine#20204, I've been increasingly unconvinced by the edge cases and user-facing complexity and surprise that `Internal` brings. Accidental queries are quite hard to write, and the entitiy-inspector concerns are really a UX problem for each tool to solve that `Internal` doesn't help with. @cart feels similarly: as a result I'm marking this PR as X-Blessed. Closes bevyengine#21363. ## Solution - Remove `Internal` as a type. - Follow the compiler errors to remove all references. - Write a migration guide.

# Objective - Allow the asset processor to run single-threaded so that asset processor tests can run in single-threaded mode too! ## Solution - Make asset hot reloading use an async channel for events instead of a crossbeam channel (which requires blocking). - Have asset processing first find all the assets it wants to process, then join all those processing tasks together. - Make the asset processing listening loop await on a stream of async channels instead of "spin-polling" (spin-lock but with polling). This should make asset processing consume less CPU! ## Testing - Tested asset processing in single threaded! It works!

# Objective Text Underline ## Solution New `Underline` marker component, add to text entities to draw an underline. This PR is based on bevyengine#21555, that should probably be reviewed and merged first.

# Objective Right now, only a very small set of atmospheres are possible with Bevy's atmospheric scattering system because of the fixed set of scattering terms available. For example, a scene set in a dry, desert environment might want a dense low-lying layer of dust particulate separate from the ambient dust in the atmosphere. This PR introduces a mechanism for generalized scattering media, replacing the fixed scattering terms with a customizable asset. ## Solution ```rust #[derive(TypePath, Asset, Clone)] pub struct ScatteringMedium { pub label: Option<Cow<'static, str>>, pub falloff_resolution: u32, pub phase_resolution: u32, pub terms: SmallVec<[ScatteringTerm; 1]>, } ``` <details> <summary>see other new types</summary> ```rust #[derive(Default, Clone)] pub struct ScatteringTerm { pub absorption: Vec3, pub scattering: Vec3, pub falloff: Falloff, pub phase: PhaseFunction, } #[derive(Default, Clone)] pub enum Falloff { #[default] Linear, Exponential { scale: f32, }, Tent { center: f32, width: f32, }, /// A falloff function defined by a custom curve. /// /// domain: [0, 1), /// range: [0, 1], Curve(Arc<dyn Curve<f32> + Send + Sync>), } #[derive(Clone)] pub enum PhaseFunction { Isotropic, Rayleigh, Mie { /// domain: [-1, 1] bias: f32, }, /// A phase function defined by a custom curve. /// /// domain: [-1, 1] /// range: [0, 1] Curve(Arc<dyn Curve<f32> + Send + Sync>), } ``` </details> `ScatteringMedium` contains a list of `ScatteringTerms`, which are processed into a set of two LUTs: - The "density LUT", a 2D `falloff_resolution x 2` LUT which contains the medium's optical density with respect to the atmosphere's "falloff parameter", a linear value which is 1.0 at the planet's surface and 0.0 at the edge of space. Absorption density and scattering density correspond to the first and second rows respectively. - The "scattering LUT", a 2D `falloff_resolution x phase_resolution` LUT which contains the medium's scattering density multiplied by the phase function, with the U axis corresponding to the falloff parameter and the V axis corresponding to `neg_LdotV * 0.5 + 0.5`, where `neg_LdotV` is the dot product of the light direction and the outgoing view vector. ## Testing - Need to verify output, should be almost exactly the same - exponential falloff is slightly different now, but verified new parameters against the old in Desmos. ## TODOS: - Docs Docs Docs - Cleanup - profile perf - reduce memory usage/traffic. This approach requires a few extra texture samples in the inner loop of each pass. Each atmosphere LUT is still quite small, but texture samples are expensive and the new LUTs use f32 texels currently. ## Showcase <details> <summary>Click to view showcase</summary> ```rust fn init_atmosphere(mut commands: Commands, scattering_media: ResMut<Assets<ScatteringMedium>>) { let earth_atmosphere = scattering_media.add( ScatteringMedium::new( 256, 256, [ // rayleigh scattering ScatteringTerm { absorption: Vec3::ZERO, scattering: Vec3::new(5.802e-6, 13.558e-6, 33.100e-6), falloff: Falloff::Exponential { scale: 12.5 }, phase: PhaseFunction::Rayleigh, }, // mie scattering ScatteringTerm { absorption: Vec3::splat(3.996e-6), scattering: Vec3::splat(0.444e-6), falloff: Falloff::Exponential { scale: 83.5 }, phase: PhaseFunction::Mie { bias: 0.8 }, }, // ozone ScatteringTerm { absorption: Vec3::new(0.650e-6, 1.881e-6, 0.085e-6), scattering: Vec3::ZERO, falloff: Falloff::Tent { center: 0.75, width: 0.3, }, phase: PhaseFunction::Isotropic, }, ], )); commands.spawn(( Camera3d::default(), Atmosphere { bottom_radius: 6_360_000.0, top_radius: 6_460_000.0, ground_albedo: Vec3::splat(0.3), medium: earth_atmosphere, }, )); } ``` </details> --------- Co-authored-by: Máté Homolya <mate.homolya@gmail.com>

…sing. (bevyengine#21550) # Objective - Workaround bevyengine#21549. ## Solution - Avoid panicking in `DiagnosticsBuffer::apply` if the world is missing the `DiagnosticsStore`. - Clear the buffer if `DiagnosticsStore` is missing to prevent growing the buffer. ## Testing - None.

# Objective Currently the docs for [`SpawnScene`](https://docs.rs/bevy/latest/bevy/app/struct.SpawnScene.html) link to the [`Main`](https://docs.rs/bevy/latest/bevy/prelude/struct.Main.html) schedule, but those docs don't mention when it runs. ## Solution Updates docs to include this information, based on the schedule ordering defined here: https://github.com/bevyengine/bevy/blob/78d940cbfe177e3585fe19145e73c76172f4085e/crates/bevy_app/src/main_schedule.rs#L222-L224

# Objective * Make DespawnOnExit more discoverable. * Fix broken link text - the parenthetical before it seems to mess it up. ## Solution * Link directly to DespawnOnExit from the module documentation instead of just the containing module. ## Testing None. Somebody should build the docs to make sure the links actually work (I'm 99% sure they do) and that the `\` added actually fixes the link on line 32 (I'm only 80% sure it does) ## Further Questions I'm wondering if this functionality should be listed in the bulleted list that precedes this paragraph. --------- Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>

) # Objective - Fixes bevyengine#20803 - See issue for motivations on this change ## Solution - Use ureq's `platform-verifier` feature and enable it in the agent config. I've gone the simple route and made this non-configurable, for now at least. The downside of this change is that you can longer use webpki-roots but if bevy only supports one certificate verification method then I think platform-verifier is the more sensible option. ## Testing - Tested the web_asset example on Windows and macOS

# Objective The docs state that `Entity::from_row` creates an entity with a generation of `1`, which was the case previously. With `Entity` internals being reworked in `0.17` however, this is no longer the case, as the generation used is now `EntityGeneration::FIRST`, currently equivalent to `0`. ## Solution This PR changes the docs to state an "unspecified" generation to allow further changes to implementation without needing another rewrite, as the docs rather consistently refer to `Entity`, `EntityRow`, and `EntityGeneration` as being opaque identifiers.

# Objective - bevyengine#21664 broke CI. Failures wasn't triggered by this PR as it's the CI that runs from the main branch ## Solution - download-artifact v5 changed how artefacts are handled. we met a case not documented in their breaking change

…engine#21647) # Objective In bevyengine#21598 and the related Discord discussion, it was pointed out that the `async_compute` example promotes an inefficient and potentially error-prone pattern: `future::block_on(poll_once)`. It is now recommended to use `bevy::tasks::futures::check_ready` instead, which is much cheaper and avoids blocking the main thread while waiting on the future. Another valid approach is to pass a channel into the async tasks and detach them, letting the channel handle task readiness. This PR implements both suggestions. ## Solution * **Updated `async_compute` example** Replaced the use of `future::block_on(poll_once)` with the recommended `check_ready`. The change is minimal and limited to the directly affected lines. * **Added new example: `async_channel_pattern`** Demonstrates how to spawn async tasks using a channel-based communication pattern. * Each task is executed on a separate thread via `AsyncComputeTaskPool`. * Results (cube positions) are sent back through a `CubeChannel` once completed. * Tasks are detached to run fully asynchronously, ensuring the main thread remains unblocked. * A rotating light in the scene visually indicates that the frame loop remains responsive. I am relatively new to both Bevy and async Rust, and I genuinely appreciate any feedback or suggestions to improve these examples — especially regarding idiomatic async patterns and best practices for Bevy task management. Fixes bevyengine#21598 --------- Co-authored-by: syszery <syszery@users.noreply.github.com> Co-authored-by: François Mockers <francois.mockers@vleue.com>

# Objective This PR is to add SSAO support on WebGPU. ## Solution Add r16float detect and fallback to r32float if not supported. FYI the initial ssao PR [here](bevyengine#7402). ## Testing - Did you test these changes? If so, how? Yes, here is the command to test the ssao example `RUSTFLAGS="--cfg getrandom_backend=\"wasm_js\"" cargo run --example ssao --target wasm32-unknown-unknown --features webgpu` and then http://localhost:1334, make sure it supports [WebGPU](https://caniuse.com/webgpu) - Are there any parts that need more testing? N/A - How can other people (reviewers) test your changes? Is there anything specific they need to know? 1. For the R32Float fallback, only the 1st commit is needed. However, I ran into some strange flickering issue on Chrome (and Chrome canary too), so I added a "detect_r16float_support" flag and a temp fix in the 2nd and 3rd commit, which are intended to be reverted when merging. 2. with the 1st commit, Safari works fine, but Chrome has the flickering, and I fixed it by partially reverting a shader change from bevyengine#20313, which is very strange. It is probably caused by some shader optimization issue in Chrome, and I have no clue why, as the change is just moving the calculation to a different function. Here is the flickering on Mac Chrome(140.0.7339.133 (Official Build) (arm64)) <img width="353" height="327" alt="chrome_ssao" src="https://github.com/user-attachments/assets/0666673f-508e-4b57-a152-19327ffdb6f3" /> - If relevant, what platforms did you test these changes on, and are there any important ones you can't test? Tested on native(mac) and WebGPU. To test on native, set "detect_r16float_support" to false to force R32Float. I couldn't make the WebGPU ssao example running on Windows 11 Chrome or Firefox, there is some error in 'taa_pipeline' . ---

# Objective Remove the `line_height` field from `TextFont`. Line height is a property of the text layout, not the font. Part of the changes for bevyengine#21175 ## Solution Remove the `line_height` field from `TextFont`. Make `LineHeight` into a component. Update the text access API and text pipeline.

# Objective - This commit refactors the `from_viewport_and_override` function to improve readability and safety. ## Solution - Replaces the initial `cloned()` and subsequent `if/else` logic with a clearer `if let` structure. - Removes the need for `unwrap()` by handling both `Some` and `None` cases ## Testing - I don't know how to make sure there is no probelm, but I run some examples and I don't see the errors.

# Objective - This PR refactors the Frustum struct to improve code readability and maintainability by replacing magic numbers with named constants and unrolling a loop for clarity. ## Testing - I ran the command 'cargo test --package bevy_camera --lib -- primitives::tests --show-output' and all the test are passed. ---

# Objective For bevyengine#17647, we want to create a `QueryData` that can follow a relation and query data from an entity's parent. If the parent does not have the queried data, the child entity should be skipped in the query. However, there is no way to tell from the child's archetype whether the parent will match! So, we need to support *non-archetypal* `QueryData`, just as we support non-archetypal `QueryFilter`s for `Added` and `Changed`. That is, if `Query<Parent<&T>>` yields `&T`, and we do: ```rust let parent1 = world.spawn(T).id(); let child1 = world.spawn(ChildOf(parent1)); let parent2 = world.spawn(()).id(); let child2 = world.spawn(ChildOf(parent2)); let query = world.query::<Parent<&T>>(); ``` then `query` must yield a row for `child1` but not for `child2`, even though they have the same archetype. ## Solution Change `QueryData::fetch` to return `Option` so that entities can be filtered during fetching by returning `None`. To support `ExactSizeIterator`, introduce an `ArchetypeQueryData` trait and an `QueryData::IS_ARCHETYPAL` associated constant, similar to `ArchetypeFilter` and `QueryFilter::IS_ARCHETYPAL`. Implement this trait on existing `QueryData` types. Modify `ExactSizeIterator` implementations to require `D: ArchetypeQueryData`, and the `size_hint()` methods to return a minimum size of `0` if `!D::IS_ARCHETYPAL`. ## Alternatives We could do nothing here, and have `Query<Parent<&T>>` yield `Option<&T>`. That makes the API less convenient, though. Note that if one *wants* to query for `Option`, they can use either `Query<Option<Parent<&T>>` or `Query<Parent<Option<&T>>`, depending on whether they want to include entities with no parent. Another option is to re-use the `ArchetypeFilter` trait instead of introducing a new one. There are no places where we want to abstract over both, however, and it would require writing bounds like `D: QueryData + ArchetypeFilter, F: QueryFilter + ArchetypeFilter` instead of simply `D: ArchetypeQueryData, F: ArchetypeFilter`. --------- Co-authored-by: Periwink <charlesbour@gmail.com>

Depends on bevyengine#20838 # Objective There's some redundant sampler bindings in the atmosphere code ## Solution Remove them ## Testing Ran the example

# Objective - Splitting out the non-BSN parts of the work on popup menus. ## Solution - Added Popover and Menu components. ## Testing - Manual testing using example. ## Showcase <img width="311" height="261" alt="popup" src="https://github.com/user-attachments/assets/ab9e8959-65bc-45d3-aa36-9d56cc09ea9d" /> --------- Co-authored-by: Viktor Gustavsson <villor94@gmail.com>

…evyengine#21643) # Objective - Fixes bevyengine#10903 ## Solution - Stop using `Path::join` for joining asset paths and instead use `AssetPath::resolve_embed`. ## Testing - Added 2 tests!

# Objective Just a tiny fix of `log_layers` example path in documentation comments. ## Solution The comments are corrected. ## Testing No needed

# Objective Allows users to override `TextColor` and use a custom color for underline and strikethrough text decorations. ## Solution New components `UnderlineColor` and `StrikethroughColor`. Add them to a text entity with `Underline` or `Strikethrough`, respectively, to use a custom color for the lines. # This could just be an optional color field on `Underline` or `Strikethrough`, that would be fine. I spent a while going back and fourth about it. The main reasons why I went with a separate component: * The same color is almost always used for both text and its decorations. Overriding `TextColor` is going to be rare. * Once we have some sort of global or propagated text style support, underline and strikethrough colors probably won't be set per entity. The single component approach has some advantages too. Discoverability, obviously. Also compare: ```rust ( Text::new("Hello"), Underline, UnderlineColor(RED.into()) ) ``` with ```rust ( Text::new("Hello"), Underline::color(RED), ) ``` which seems clearly nicer. If it weren't for the planned non-entity-local text styling support, I'd lean more towards the single component approach. ## Testing Added a few color overrides to this example: ``` cargo run --example strikethrough ``` ## Showcase <img width="1924" height="1127" alt="strike-under-color" src="https://github.com/user-attachments/assets/83664f95-0926-4ccb-81e4-a3059cd2ccf3" />

…bevyengine#21685) # Objective Tests should be more resilient to entities added on `World` creation. This is necessary for resources-as-components to work without relying on `DefaultQueryFilters`. ## Solution I've added an empty entity during `World::bootstrap()` and ran the test suite (and CI). I've gone and fixed every test, except for the ones where it's not possible / doesn't make sense. Both `iter_entities` and `iter_entities_mut` and their tests have been removed as they were deprecated in 0.17.

# Objective - Computing the ndc from a viewport coordinates is already done in a few places. - It's can be useful for users, not just internally. ## Solution - Extract it to a function ## Testing - I'm using it in a currently unfinished PR for gpu picking and things worked as expected - I also tested 3d_viewport_to_world and 2d_viewport_to_world --------- Co-authored-by: atlv <email@atlasdostal.com>

…_2d_as_array` (bevyengine#21628) # Objective If you want to use a `TilemapChunk` (or more generally use a `texture2DArray` in a shader), you have to implement a mechanism that waits for your texture to load, then calls `Image::reinterpret_stacked_2d_as_array`. ## Solution Have the loader do it instead. Closes bevyengine#20799, which does very similar things and should be remade if more functionality is needed. ## Testing - Ran the updated examples --- ## Showcase ```rs let array_texture = asset_server.load_with_settings( "textures/array_texture.png", |settings: &mut ImageLoaderSettings| { settings.array_layout = Some(ImageArrayLayout::RowCount(4)); }, ); ```

# Objective Ended up with two release notes for strikethrough somehow after the merges or whatever. ## Solution Rename one, delete the other.

…evyengine#21689) # Objective Rename the example, fix a typo in its ("it's") comments.

# Objective Follow up to the underline and strikethrough PRs: * Replace the quintuples stored in `TextLayoutInfo::section_geometry` with a struct with named fields. * Rename `TextLayoutInfo::section_geometry` because "section" in our terminology implies a one-to-one correspondence with text entities. * Add some basic helpers to construct the underline and strikethrough lines. * Seperate the thickness values for underline and strikethrough. This is needed for an API that allows users to set custom thicknesses. ## Solution * New struct `RunGeometry`. `RunGeometry` holds the bounds and decoration geometry for each text run (a contiguous sequence of glyphs on a line that share text attributes). It has helper methods for placing underline and strikethrough. * Rename the `section_geometry` field to `run_geometry` and make it a `Vec<RunGeometry>` * `RunGeometry` has seperate `underline_thickness` and `strikethrough_thickness` values.

# Objective Some macros were handling Idents and indexes as seperate things, we can use syn::Member to make this more readable and nicer. revive of bevyengine#18199

…yengine#16396) # Objective Improve the performance of some dynamic queries with `FilteredEntity(Ref|Mut)` by allowing dense iteration in more cases, and remove a call to the sort-of deprecated `Access::component_reads_and_writes()` method. `QueryBuilder` currently requires sparse iteration if any sparse set components may be read. We do need sparse iteration if sparse set components are used in the filters, but `FilteredEntityRef` can still perform dense iteration when reading optional components or when reading all components. Note that the optional case is different from `Option`, which performs sparse iteration when the inner query is sparse so that it can cache whether the inner query matches for an entire archetype. ## Solution Change `FilteredEntity(Ref|Mut)` to have `IS_DENSE = true`. It used to require sparse iteration in order to filter the `Access` for each archetype, but bevyengine#15207 changed it to copy the entire access. Change `QueryBuilder::is_dense()` to check `D::IS_DENSE && F::IS_DENSE` instead of looking at the component reads and writes. `QueryBuilder::is_dense()` still checks the *filters*, so `builder.data::<&Sparse>()` will still cause sparse iteration, but `builder.data::<Option<&Sparse>>()` no longer will. I believe this is sound, even in the presence of query transmutes. The only `WorldQuery` implementations that rely on a sparse query being sparse for soundness are `&`, `&mut`, `Ref`, and `Mut`, but they can only be transmuted to if the component is in the `required` set. If a dynamic query has the component in the `required` set, then it appears in the filters and the query will use sparse iteration. Note that `Option` and `Has` will misbehave and report `None` and `false` for all entities if they do a dense query while wrapping a sparse component, but they won't cause UB. And it's already possible to hit that case by transmuting from `Query<EntityMut>` to `Query<Option<&Sparse>>`.

# Objective Have the layout of the tile chunk map the world axis. ## Solution Invert the calculated y index in the shader and transform calculation. ## Testing Ran the example and saw 0,0 move to the bottom left instead of the top left. ## Migration People manually calculating the tile index will have to invert the chunk relative y index from the current implementation. For example, with a chunk size of (16, 16) today: (5, 6) in world coords => (5, 9) in chunk coords Changes to: (5, 6) in world coords => (5, 6) in chunk coords --------- Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com> Co-authored-by: Martín Maita <47983254+mnmaita@users.noreply.github.com>

# Objective Text2d underline shadow is being drawn using the strikethrough position and size values. Draw it with the correct geometry. ## Solution Use the underline values.

…ources. (bevyengine#21673) # Objective - Trying to rewrite asset processing to be dynamic is hard, especially since we don't have tests verifying all the situations asset processing is supposed to be able to handle! ## Solution - Add a couple more tests! One to check that processing multiple sources works, and another to check that sending asset events triggers processing (including processing of dependent processing). ## Testing - ;)

WaterWhisperer and others added 30 commits October 19, 2025 17:30

Updated docs for bevy::render::RenderSystems (bevyengine#21586)

14a3c9d

# Objective - Fixes bevyengine#16654 ## Solution - Updated the doc string and linked to TemporaryRenderEntity. ## Testing - Built the documentation locally and verified that the links render and navigate correctly.

Move tick.rs into change_detection module (bevyengine#21613)

5663ff3

Follow-up to bevyengine#21604. `Tick` and friends should be in the `change_detection` module, not `component`.

dont re-export SamplerBindingType twice for no reason (bevyengine#21618)

46b403f

# Objective - dont re-export SamplerBindingType twice for no reason ## Solution - dont re-export SamplerBindingType twice for no reason ## Testing - ci

Move asset processing tests to their own file. (bevyengine#21567)

78d940c

# Objective - Address [this comment](bevyengine#21566 (comment)). ## Solution - Move all the asset processor tests into their own file. ## Testing - Ran the tests in single threaded and multi threaded mode.

fix dead links in Mesh2d doc comment (bevyengine#21627)

bcee375

at some point, the things it was pointing to were moved from bevy/sprite to bevy/prelude, so fix the link to point there

Text underline (bevyengine#21559)

d5a16b7

# Objective Text Underline ## Solution New `Underline` marker component, add to text entities to draw an underline. This PR is based on bevyengine#21555, that should probably be reviewed and merged first.

mockersf and others added 29 commits October 28, 2025 20:55

Atmosphere bindings cleanup (bevyengine#21625)

0fa0b0e

Depends on bevyengine#20838 # Objective There's some redundant sampler bindings in the atmosphere code ## Solution Remove them ## Testing Ran the example

Fix GLTF files being broken when loaded from custom asset sources. (b…

f6b34bd

…evyengine#21643) # Objective - Fixes bevyengine#10903 ## Solution - Stop using `Path::join` for joining asset paths and instead use `AssetPath::resolve_embed`. ## Testing - Added 2 tests!

Fix example file paths in doc comments (bevyengine#21674)

a5b9c41

# Objective Just a tiny fix of `log_layers` example path in documentation comments. ## Solution The comments are corrected. ## Testing No needed

Strikethrough release note clean up (bevyengine#21688)

0067171

# Objective Ended up with two release notes for strikethrough somehow after the merges or whatever. ## Solution Rename one, delete the other.

Rename the strikethrough example to strikethrough_and_underline (b…

8d1bf6e

…evyengine#21689) # Objective Rename the example, fix a typo in its ("it's") comments.

Cleaner macros utilizing syn::Member v2 (bevyengine#21678)

5a6a06a

# Objective Some macros were handling Idents and indexes as seperate things, we can use syn::Member to make this more readable and nicer. revive of bevyengine#18199

Text2d underline shadows fix (bevyengine#21695)

346c47c

# Objective Text2d underline shadow is being drawn using the strikethrough position and size values. Draw it with the correct geometry. ## Solution Use the underline values.

Skip BG cache and assume D2 textures to get things working for now

3a1ad7d

Suppress unused

ebc3e77

Docs

10e6423

Merge commit '906bc14d735b0f29ca4faf1c3f39aff9080da94a' into render-api2

ed8ff39

JMS55 merged commit 044938b into JMS55:render-api Oct 31, 2025
23 of 29 checks passed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Render api2#41

Render api2#41
JMS55 merged 64 commits intoJMS55:render-apifrom
jasmine-nominal:render-api2

jasmine-nominal commented Oct 31, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

20 participants

Conversation

jasmine-nominal commented Oct 31, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

20 participants