Custom render phase rebased #12
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
# Objective `SubApps` is visible within the documentation for `bevy_app`. However, no way of accessing the `SubApps` field in `App` is currently available. ## Solution Expose two new functions, `App::sub_apps()` and `App::sub_apps_mut()`, which give immutable and mutable access to `SubApps` respectively. The other solution is to hide `SubApps`, which I submitted as a PR at <bevyengine#16953>. ## Testing Because of the simplicity of the changes, I only tested by compiling `bevy_app` - which compiled successfully. Note: `SubApps`, and its corresponding field on `App`, are not used outside of `bevy_app` - which means that compiling the other crates is not necessary.
# Objective With the introduction of bevy_input_focus, the uses of "focus" in bevy_picking are quite confusing and make searching hard. Users will intuitively think these concepts are related, but they actually aren't. ## Solution Rename / rephrase all uses of "focus" in bevy_picking to refer to "hover", since this is ultimately related to creating the `HoverMap`. ## Migration Guide Various terms related to "focus" in `bevy_picking` have been renamed to refer to "hover" to avoid confusion with `bevy_input_focus`. In particular: - The `update_focus` system has been renamed to `generate_hovermap` - `PickSet::Focus` and `PostFocus` have been renamed to `Hover` and `PostHover` - The `bevy_picking::focus` module has been renamed to `bevy_picking::hover` - The `is_focus_enabled` field on `PickingPlugin` has been renamed to `is_hover_enabled` - The `focus_should_run` run condition has been renamed to `hover_should_run`
# Summary - I started experimenting if `TextureAtlas` and friends can be moved to `bevy_image`. See [Discord](https://discord.com/channels/691052431525675048/692572690833473578/1320176054911897642) thread. - While doing that, and moving `DynamicTextureAtlasBuilder` to `bevy_image`, it revealed that `DynamicTextureAtlasBuilder` depends on `bevy_render::GpuImage`, but we can't have `bevy_image` depend on `bevy_render`. - The reason for the dependency is an assertion introduced in [this PR](https://github.com/bevyengine/bevy/pull/12827/files?show-viewed-files=true&file-filters%5B%5D=#diff-d9afd2170466f4aae340b244bdaa2a80aef58e979268c003878ca6c95860eb37R59). - [It doesn't seem like there was a specific reason for that change](https://discord.com/channels/691052431525675048/743663924229963868/1320506862067650580), so should be safe to change it. - So instead of the cast, just look up `asset_usage` directly on the concrete `Image` type. - Also update the message which referred to a non-existent variable `atlas_texture_handle` (it was renamed during a subsequent refactor PR). # Testing - Checked on Discord if there was any known reason this had to stay like this. - CI builds it.
…ne#16957) # Objective Almost all of the `*InOut` easing functions are not actually smooth (`SineInOut` is the one exception). Because they're defined piecewise, they jump from accelerating upwards to accelerating downwards, causing infinite jerk at t=½. ## Solution This PR adds the well-known [smoothstep](https://registry.khronos.org/OpenGL-Refpages/gl4/html/smoothstep.xhtml), as well as its higher-degree version [smootherstep](https://en.wikipedia.org/wiki/Smoothstep#Variations), as easing functions. Mathematically, these are the classic [Hermite interpolation](https://en.wikipedia.org/wiki/Hermite_interpolation) results: - for smoothstep, the cubic with velocity zero at both ends - for smootherstep, the quintic with velocity zero *and acceleration zero* at both ends And because they're simple polynomials, there's no branching and thus they don't have the acceleration jump in the middle. I also added some more information and cross-linking to the documentation for these and some of the other easing functions, to help clarify why one might want to use these over other existing ones. In particular, I suspect that if people are willing to pay for a quintic they might prefer `SmootherStep` to `QuinticInOut`. For consistency with how everything else has triples, I added `Smooth(er)Step{In,Out}` as well, in case people want to run the `In` and `Out` versions separately for some reason. Qualitatively they're not hugely different from `Quadratic{In,Out}` or `Cubic{In,Out}`, though, so could be removed if you'd rather. They're low cost to keep, though, and convenient for testing. ## Testing These are simple polynomials, so their coefficients can be read directly from the Horner's method implementation and compared to the reference materials. The tests from bevyengine#16910 were updated to also test these 6 new easing functions, ensuring basic behaviour, plus one was updated to better check that the InOut versions of things match their rescaled In and Out versions. Even small changes like ```diff - (((2.5 + (-1.875 + 0.375*t) * t) * t) * t) * t + (((2.5 + (-1.85 + 0.375*t) * t) * t) * t) * t ``` are caught by multiple tests this way. If you want to confirm them visually, here are the 6 new ones graphed: <https://www.desmos.com/calculator/2d3ofujhry>  --- ## Migration Guide This version of bevy marks `EaseFunction` as `#[non_exhaustive]` to that future changes to add more easing functions will be non-breaking. If you were exhaustively matching that enum -- which you probably weren't -- you'll need to add a catch-all (`_ =>`) arm to cover unknown easing functions.
# Objective - To fix the benches panicking on `main` ## Solution - It appears that systems requiring access to a non-existing `Res` now causes a panic - Some of the benches run systems that access resources that have not been inserted into the world - I have made it so that those resources are inserted into the world ## Testing - I ran all the ecs benches and they all run without panicking Co-authored-by: Oliver Maskery <[email protected]>
# Objective
Make it so that users can ease between tuples of easeable values.
## Solution
Use `variadics_please`'s `all_tuples_enumerated` macro to generate code
that creates these trait implementations. For two elements, the result
looks like this:
```rust
impl<T0: Ease, T1: Ease> Ease for (T0, T1) {
fn interpolating_curve_unbounded(start: Self, end: Self) -> impl Curve<Self> {
let curve_tuple = (
<T0 as Ease>::interpolating_curve_unbounded(start.0, end.0),
<T1 as Ease>::interpolating_curve_unbounded(start.1, end.1),
);
FunctionCurve::new(Interval::EVERYWHERE, move |t| {
(
curve_tuple.0.sample_unchecked(t),
curve_tuple.1.sample_unchecked(t),
)
})
}
}
```
## Testing
It compiles, and I futzed about with some manual examples, which seem to
work as expected.
---
## Showcase
Easing curves now support easing tuples of values that can themselves be
eased. For example:
```rust
// Easing between two `(Vec3, Quat)` values:
let easing_curve = EasingCurve::new(
(vec3(0.0, 0.0, 0.0), Quat::from_rotation_z(-FRAC_PI_2)),
(vec3(1.0, 1.0, 1.0), Quat::from_rotation_z(FRAC_PI_2)),
EaseFunction::ExponentialInOut
);
```
# Objective Fixes bevyengine#16850 ## Solution Add a new function `SubApp::take_extract()`, similar to `Option::take()`, which allows stealing the currently installed extract function of a sub-app, with the intent to replace it with a custom one calling the original one via `set_extract()`. This pattern enables registering a custom "world sync" function similar to the existing one `entity_sync_system()`, to run custom world sync logic with mutable access to both the main and render worlds. ## Testing `cargo r -p ci` currently doesn't build locally, event after upgrading rustc to latest and doing a `cargo update`.
# Objective
- Running example `load_gltf` when not using bindless gives this error
```
ERROR bevy_render::render_resource::pipeline_cache: failed to process shader:
error: no definition in scope for identifier: 'slot'
┌─ crates/bevy_pbr/src/render/pbr_fragment.wgsl:153:13
│
153 │ slot,
│ ^^^^ unknown identifier
│
= no definition in scope for identifier: 'slot'
```
- since bevyengine#16825
## Solution
- Set `slot` to the expected value when not mindless
- Also use it for `uv_b`
## Testing
- Run example `load_gltf` on a Mac or in wasm
# Objective Fixes bevyengine#16978 While testing, discovered that the morph weight interface in `scene_viewer` has been broken for a while (panics when loaded model has morph weights), probably since bevyengine#15591. Fixed that too. While testing, saw example text in morph interface with [wrong padding](https://bevyengine.org/learn/contribute/helping-out/creating-examples/#visual-guidelines). Fixed that too. Left the small font size because there may be a lot of morphs to display, so that seems intentional. ## Solution Use normal queries and bail early ## Testing Morph interface can be tested with ``` cargo run --example scene_viewer assets/models/animated/MorphStressTest.gltf ``` ## Discussion I noticed that this fix is different than what is happening in bevyengine#16976. Feel free to discard this for an alternative fix. I opened this anyway to document the issue with morph weight display. This is on top of bevyengine#16966 which is required to test. --------- Co-authored-by: François Mockers <[email protected]> Co-authored-by: François Mockers <[email protected]>
A previous PR, bevyengine#14599, attempted to enable lightmaps in deferred mode, but it still used the `OpaqueNoLightmap3dBinKey`, which meant that it would be broken if multiple lightmaps were used. This commit fixes that issue, and allows bindless lightmaps to work with deferred rendering as well.
# Objective Resolve bevyengine#16745 ## Solution Provide a way to map `AppTypeRegistry` types into a JSON Schema that can be used in other applications. I took code from https://github.com/kaosat-dev/Blenvy as a starting point, cleaned up and adapter more for `bevy_remote` needs. Based on feedback and needs it could be improved, I could add some filtering options, etc. ## Testing - I was comparing results with the ones from code in `blenvy` - There is added unit test, could be added more - I was testing it in my game with this code: ```rust fn types_to_file(world: &mut World) { use bevy_remote::builtin_methods::export_registry_types; let Ok(Ok(types_schema)) = world.run_system_cached_with(export_registry_types, None) else { return; }; let registry_save_path = std::path::Path::new("assets").join("registry.json"); let writer = std::fs::File::create(registry_save_path).expect("should have created schema file"); serde_json::to_writer_pretty(writer, &types_schema).expect("Failed to save types to file"); } ``` It can be run by adding it at startup ```rust app.add_systems(Startup, types_to_file); ``` --------- Co-authored-by: Gino Valente <[email protected]>
# Objective Fixes bevyengine#16607 ## Solution Satisfy clippy ## Testing Ran clippy
# Objective ensure that `animate_targets` runs **before** `bevy_render::mesh::inherit_weights` to address the one-frame delay Fixes bevyengine#16554 ## Solution switch ordering constraints from `after` to `before` ## Testing ran bevy_animation tests and the animated_fox example on MacOS
# Objective - Please see bevyengine#16647 for the full reasoning behind this change. ## Solution - Create the `bench!` macro, which generates the name of the benchmark at compile time. Migrating is a single line change, and it will automatically update if you move the benchmark to a different module: ```diff + use benches::bench; fn my_benchmark(c: &mut Criterion) { - c.bench_function("my_benchmark", |b| {}); + c.bench_function(bench!("my_benchmark"), |b| {}); } ``` - Migrate all reflection benchmarks to use `bench!`. - Fix a few places where `black_box()` or Criterion is misused. ## Testing ```sh cd benches # Will take a long time! cargo bench --bench reflect # List out the names of all reflection benchmarks, to ensure I didn't miss anything. cargo bench --bench reflect -- --list # Check for linter warnings. cargo clippy --bench reflect # Run each benchmark once. cargo test --bench reflect ```
# Objective - First step for bevyengine#16718 - bevyengine#16589 introduced an api that can only ignore errors, which is risky ## Solution - Panic instead of just ignoring the errors ## Testing - Changed the `fallible_systems` example to return an error ``` Encountered an error in system `fallible_systems::setup`: TooManyVertices { subdivisions: 300, number_of_resulting_points: 906012 } Encountered a panic in system `fallible_systems::setup`! Encountered a panic in system `bevy_app::main_schedule::Main::run_main`! ```
# Objective - Fixes bevyengine#16959 - The `pbr.rs` example in the 3d section panicked because of the changes in bevyengine#16638, that was not supposed to happen ## Solution - For now it's sufficient to introduce a `never_param_warn` call when adding the fallible system into the app ## Testing - Tested on my machine via `cargo r --example pbr`, it built and ran successfully --------- Co-authored-by: Freya Pines <[email protected]> Co-authored-by: François Mockers <[email protected]>
# Objective Fixes bevyengine#16104 ## Solution I removed all instances of `:?` and put them back one by one where it caused an error. I removed some bevy_utils helper functions that were only used in 2 places and don't add value. See: bevyengine#11478 ## Testing CI should catch the mistakes ## Migration Guide `bevy::utils::{dbg,info,warn,error}` were removed. Use `bevy::utils::tracing::{debug,info,warn,error}` instead. --------- Co-authored-by: SpecificProtagonist <[email protected]>
# Objective - Contributes to bevyengine#15460 ## Solution - Added the following features: - `std` (default) ## Testing - CI ## Notes - There was a minor issue with `bevy_reflect`'s `smallvec` feature noticed in this PR which I have also resolved here. I can split this out if desired, but I've left it here for now as it's a very small change and I don't consider this PR itself to be very controversial.
…#16881) # Objective - Updates the linux-dependencies docs to 1) fix problems with nix `alsa-lib`, and 2) include additional documentation to run bevy with nix on non NixOS systems. (nix is a package manager that can be run outside of NixOS). ## Solution 1. the nix `alsa-lib` package doesn't include `alsa-plugins`, which bevy depends on. Instead, use the `alsa-lib-with-plugins` package, which wraps `alsa-plugins` into `alsa-lib`. For more information see: NixOS/nixpkgs#277180 2. using nix on non NixOS systems, software like `nixGL` is required to correctly link graphics drivers. ## Testing - Tested on ubuntu 22.04 with nix.
# Objective The way `Curve` presently achieves dyn-compatibility involves shoving `Self: Sized` bounds on a bunch of methods to forbid them from appearing in vtables. (This is called *explicit non-dispatchability*.) The `Curve` trait probably also just has way too many methods on its own. In the past, using extension traits instead to achieve similar functionality has been discussed. The upshot is that this would allow the "core" of the curve trait, on which all the automatic methods rely, to live in a very simple dyn-compatible trait, while other functionality is implemented by extensions. For instance, `dyn Curve<T>` cannot use the `Sized` methods, but `Box<dyn Curve<T>>` is `Sized`, hence would automatically implement the extension trait, containing the methods which are currently non-dispatchable. Other motivations for this include modularity and code organization: the `Curve` trait itself has grown quite large with the addition of numerous adaptors, and refactoring it to demonstrate the separation of functionality that is already present makes a lot of sense. Furthermore, resampling behavior in particular is dependent on special traits that may be mimicked or analogized in user-space, and creating extension traits to achieve similar behavior in user-space is something we ought to encourage by example. ## Solution `Curve` now contains only `domain` and the `sample` methods. `CurveExt` has been created, and it contains all adaptors, along with the other sampling convenience methods (`samples`, `sample_iter`, etc.). It is implemented for all `C` where `C: Curve<T> + Sized`. `CurveResampleExt` has been created, and it contains all resampling methods. It is implemented for all `C` where `C: Curve<T> + ?Sized`. ## Testing It compiles and `cargo doc` succeeds. --- ## Future work - Consider writing extension traits for resampling curves in related domains (e.g. resampling for `Curve<T>` where `T: Animatable` into an `AnimatableKeyframeCurve`). - `CurveExt` might be further broken down to separate the adaptor and sampling methods. --- ## Migration Guide `Curve` has been refactored so that much of its functionality is now in extension traits. Adaptors such as `map`, `reparametrize`, `reverse`, and so on now require importing `CurveExt`, while the resampling methods `resample_*` require importing `CurveResampleExt`. Both of these new traits are exported through `bevy::math::curve` and through `bevy::math::prelude`.
# Objective Follow-up to bevyengine#16984 ## Solution Fix the lint ## Testing ``` PS C:\Users\BenjaminBrienen\source\bevy> cargo clippy Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.71s PS C:\Users\BenjaminBrienen\source\bevy> cargo clippy -p bevy_ecs Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.21s ```
…_tasks` (bevyengine#16951) # Objective - Related to bevyengine#11478 ## Solution - Moved `futures.rs`, `ConditionalSend` `ConditionalSendFuture` and `BoxedFuture` from `bevy_utils` to `bevy_tasks`. ## Testing - CI checks ## Migration Guide - Several modules were moved from `bevy_utils` into `bevy_tasks`: - Replace `bevy_utils::futures` imports with `bevy_tasks::futures`. - Replace `bevy_utils::ConditionalSend` with `bevy_tasks::ConditionalSend`. - Replace `bevy_utils::ConditionalSendFuture` with `bevy_tasks::ConditionalSendFuture`. - Replace `bevy_utils::BoxedFuture` with `bevy_tasks::BoxedFuture`.
…bevyengine#16994) # Objective Incorrect default value for ChromatticAberration intensity, missing a zero. Bevy 0.15
# Objective - This reverts bevyengine#16833, and completely goes against bevyengine#16803. - Turns out running `cargo test --benches` runs each benchmark once, without timing it, just to ensure nothing panics. This is actually desired because we can use it to verify benchmarks are working correctly without all the time constraints of actual benchmarks. ## Solution - Add the `--benches` flag to the CI test command. ## Testing - `cargo run -p ci -- test`
# Objective Many of our benchmarks use [`criterion::black_box()`](https://docs.rs/criterion/latest/criterion/fn.black_box.html), which is used to prevent the compiler from optimizing away computation that we're trying to time. This can be slow, though, because `criterion::black_box()` forces a point read each time it is called through [`ptr::road_volatile()`](https://doc.rust-lang.org/stable/std/ptr/fn.read_volatile.html). In Rust 1.66, the standard library introduced [`core::hint::black_box()`](https://doc.rust-lang.org/nightly/std/hint/fn.black_box.html) (and `std::hint::black_box()`). This is an intended replacement for `criterion`'s version that uses compiler intrinsics instead of volatile pointer reads, and thus has no runtime overhead. This increases benchmark accuracy, which is always nice 👍 Note that benchmarks may _appear_ to improve in performance after this change, but that's just because we are eliminating the pointer read overhead. ## Solution - Deny `criterion::black_box` in `clippy.toml`. - Fix all imports. ## Testing - `cargo clippy -p benches --benches`
…yengine#16958) # Objective Fixes bevyengine#16879 ## Solution Moved the construction of the root path of the assets folder out of `FileWatcher::new()` and into `source.rs`, as the path is checked there with `path.exists()` and fails in certain configurations eg., virtual workspaces. ## Testing Applied fix to a private fork and tested against both standard project setups and virtual workspaces. Works without issue on both. Have tested under macOS and Arch Linux. --------- Co-authored-by: JP Stringham <[email protected]> Co-authored-by: Alice Cecile <[email protected]>
…evyengine#16968) # Objective Fixes bevyengine#16683 ## Solution Make all fields ine `RawHandleWrapper` private. ## Testing - CI - `cargo clippy` - The lightmaps example --- ## Migration Guide The `window_handle` and `dispay_handle` fields on `RawHandleWrapper` are no longer public. Use the newly added getters and setters to manipulate them instead.
# Objective The rust-versions are out of date. Fixes bevyengine#17008 ## Solution Update the values Cherry-picked from bevyengine#17006 in case it is controversial ## Testing Validated locally and in bevyengine#17006 --------- Co-authored-by: Alice Cecile <[email protected]>
# Objective - Part of bevyengine#16647. - The benchmarks for bezier curves have several issues and do not yet use the new `bench!` naming scheme. ## Solution - Make all `bevy_math` benchmarks use the `bench!` macro for their name. - Delete the `build_accel_cubic()` benchmark, since it was an exact duplicate of `build_pos_cubic()`. - Remove `collect::<Vec<_>>()` call in `build_pos_cubic()` and replace it with a `for` loop. - Combine all of the benchmarks that measure `curve.position()` under a single group, `curve_position`, and extract the common bench routine into a helper function. - Move the time calculation for the `curve.ease()` benchmark into the setup closure so it is not tracked. - Rename the benchmarks to be more descriptive on what they do. - `easing_1000` -> `segment_ease` - `cubic_position_Vec2` -> `curve_position/vec2` - `cubic_position_Vec3A` -> `curve_position/vec3a` - `cubic_position_Vec3` -> `curve_position/vec3` - `build_pos_cubic_100_points` -> `curve_iter_positions` ## Testing - `cargo test -p benches --bench math` - `cargo bench -p benches --bench math` - Then open `./target/criterion/report/index.html` to see the report! --------- Co-authored-by: Alice Cecile <[email protected]>
…tyWorldMut` (bevyengine#16999) ## Objective Commands were previously limited to structs that implemented `Command`. Now there are blanket implementations for closures, which (in my opinion) are generally preferable. Internal commands within `commands/mod.rs` have been switched from structs to closures, but there are a number of internal commands in other areas of the engine that still use structs. I'd like to tidy these up by moving their implementations to methods on `World`/`EntityWorldMut` and changing `Commands` to use those methods through closures. This PR handles the following: - `TriggerEvent` and `EmitDynamicTrigger` double as commands and helper structs, and can just be moved to `World` methods. - Four structs that enabled insertion/removal of components via reflection. This functionality shouldn't be exclusive to commands, and can be added to `EntityWorldMut`. - Five structs that mostly just wrapped `World` methods, and can be replaced with closures that do the same thing. ## Solution - __Observer Triggers__ (`observer/trigger_event.rs` and `observer/mod.rs`) - Moved the internals of `TriggerEvent` to the `World` methods that used it. - Replaced `EmitDynamicTrigger` with two `World` methods: - `trigger_targets_dynamic` - `trigger_targets_dynamic_ref` - `TriggerTargets` was now the only thing in `observer/trigger_event.rs`, so it's been moved to `observer/mod.rs` and `trigger_event.rs` was deleted. - __Reflection Insert/Remove__ (`reflect/entity_commands.rs`) - Replaced the following `Command` impls with equivalent methods on `EntityWorldMut`: - `InsertReflect` -> `insert_reflect` - `InsertReflectWithRegistry` -> `insert_reflect_with_registry` - `RemoveReflect` -> `remove_reflect` - `RemoveReflectWithRegistry` -> `remove_reflect_with_registry` - __System Registration__ (`system/system_registry.rs`) - The following `Command` impls just wrapped a `World` method and have been replaced with closures: - `RunSystemWith` - `UnregisterSystem` - `RunSystemCachedWith` - `UnregisterSystemCached` - `RegisterSystem` called a helper function that basically worked as a constructor for `RegisteredSystem` and made sure it came with a marker component. That helper function has been replaced with `RegisteredSystem::new` and a `#[require]`. ## Possible Addition The extension trait that adds the reflection commands, `ReflectCommandExt`, isn't strictly necessary; we could just `impl EntityCommands`. We could even move them to the same files as the main impls and put it behind a `#[cfg]`. The PR that added it [had a similar conversation](bevyengine#8895 (comment)) and decided to stick with the trait, but we could revisit it here if so desired.
Found a few missing full-stops, etc.
fix typo query.rs
# Objective resolves bevyengine#17326. ## Solution Simply added the suggested run condition. ## Testing A self-explanatory run condition. Fully verified by the operation of `QueryFilter` in a system.
# Objective - Currently, the `ObservedBy`-component is only public within the `bevy_ecs` crate. Sometimes it is desirable to refer to this component in the "game-code". Two examples that come in mind: - Clearing all components in an entity, but intending to keep the existing observers: Making `ObservedBy` public allows us to use `commands.entity(entity).retain::<ObservedBy>();`, which clears all other components, but keeps `ObservedBy`, which prevents the Observers from despawning. - The opposite of the above, clearing all of entities' Observers: `commands.entity(entity).remove::<ObservedBy>` will despawn all associated Observers. Admittedly, a cleaner solution would be something like `commands.entity(entity).clear_observers()`, but this is sufficient. ## Solution - Removed `(crate)` "rule" and added `ObservedBy` to the prelude-module ## Testing - Linked `bevy_ecs` locally with another project to see if `ObservedBy` could be referenced.
# Objective Support the parametrization of the WS_CLIPCHILDREN style on Windows. Fixes bevyengine#16544 ## Solution Added a window configuration in bevy_winit to control the usage of the WS_CLIPCHILDREN style. ## Testing - Did you test these changes? If so, how? I did. I was able to create a Wry Webview with a transparent HTML document and was also able to see my Bevy scene behind the webview elements. - Are there any parts that need more testing? I don't believe so. I assume the option is extensively tested within winit itself. - How can other people (reviewers) test your changes? Is there anything specific they need to know? Test repositiory [here](https://github.com/nicholasc/bevy_wry_test). Bevy's path will need to be updated in the Cargo.toml - If relevant, what platforms did you test these changes on, and are there any important ones you can't test? This is a Windows specific issue. Should be tested accordingly. --------- Co-authored-by: jf908 <[email protected]>
# Objective - Bevy 0.15 added support for custom cursor images in bevyengine#14284. - However, to do animated cursors using the initial support shipped in 0.15 means you'd have to animate the `Handle<Image>`: You can't use a `TextureAtlas` like you can with sprites and UI images. - For my use case, my cursors are spritesheets. To animate them, I'd have to break them down into multiple `Image` assets, but that seems less than ideal. ## Solution - Allow users to specify a `TextureAtlas` field when creating a custom cursor image. - To create parity with Bevy's `TextureAtlas` support on `Sprite`s and `ImageNode`s, this also allows users to specify `rect`, `flip_x` and `flip_y`. In fact, for my own use case, I need to `flip_y`. ## Testing - I added unit tests for `calculate_effective_rect` and `extract_and_transform_rgba_pixels`. - I added a brand new example for custom cursor images. It has controls to toggle fields on and off. I opted to add a new example because the existing cursor example (`window_settings`) would be far too messy for showcasing these custom cursor features (I did start down that path but decided to stop and make a brand new example). - The new example uses a [Kenny cursor icon] sprite sheet. I included the licence even though it's not required (and it's CC0). - I decided to make the example just loop through all cursor icons for its animation even though it's not a _realistic_ in-game animation sequence. - I ran the PNG through https://tinypng.com. Looks like it's about 35KB. - I'm open to adjusting the example spritesheet if required, but if it's fine as is, great. [Kenny cursor icon]: https://kenney-assets.itch.io/crosshair-pack --- ## Showcase https://github.com/user-attachments/assets/8f6be8d7-d1d4-42f9-b769-ef8532367749 ## Migration Guide The `CustomCursor::Image` enum variant has some new fields. Update your code to set them. Before: ```rust CustomCursor::Image { handle: asset_server.load("branding/icon.png"), hotspot: (128, 128), } ``` After: ```rust CustomCursor::Image { handle: asset_server.load("branding/icon.png"), texture_atlas: None, flip_x: false, flip_y: false, rect: None, hotspot: (128, 128), } ``` ## References - Feature request [originally raised in Discord]. [originally raised in Discord]: https://discord.com/channels/691052431525675048/692572690833473578/1319836362219847681
…out_reason)]` to the workspace `Cargo.toml` (bevyengine#17374) # Objective Fixes bevyengine#17111 ## Solution Move `#![warn(clippy::allow_attributes, clippy::allow_attributes_without_reason)]` to the workspace `Cargo.toml` ## Testing Lots of CI testing, and local testing too. --------- Co-authored-by: Benjamin Brienen <[email protected]>
…6600) # Objective - Implement ForwardDecal as outlined in bevyengine#2401 ## Solution - Port https://github.com/naasblod/bevy_contact_projective_decals, and cleanup the API a little. ## Testing - Ran the new decal example. --- ## Showcase  ## Changelog * Added ForwardDecal and associated types * Added MaterialExtension::alpha_mode() --------- Co-authored-by: IceSentry <[email protected]>
# Objective - Follow up work from bevyengine#17121 (comment) to keep the `cursor.rs` file more manageable. ## Solution - Move `CustomCursor` and make it compile. ## Testing - Ran the example: `cargo run --example custom_cursor_image --features=custom_cursor` - CI
I noticed that this component was not being returned correctly by the
`bevy_remote` api
```json
"errors": {
"bevy_picking::focus::PickingInteraction": {
"code": -23402,
"message": "Unknown component type: `bevy_picking::focus::PickingInteraction`"
}
}
```
# Objective UI node Outlines are clipped using their parent's clipping rect instead of their own. ## Solution Clip outlines using the UI node's own clipping rect.
…Component (bevyengine#17380) # Objective As raised in bevyengine#17317, the `Event: Component` trait bound is confusing to users. In general, a type `E` (like `AppExit`) which implements `Event` should not: - be stored as a component on an entity - be a valid option for `Query<&AppExit>` - require the storage type and other component metadata to be specified Events are not components (even if they one day use some of the same internal mechanisms), and this trait bound is confusing to users. We're also automatically generating `Component` impls with our derive macro, which should be avoided when possible to improve explicitness and avoid conflicts with user impls. Closes bevyengine#17317, closes bevyengine#17333 ## Solution - We only care that each unique event type gets a unique `ComponentId` - dynamic events need their own tools for getting identifiers anyways - This avoids complicating the internals of `ComponentId` generation. - Clearly document why this cludge-y solution exists. In the medium term, I think that either a) properly generalizing `ComponentId` (and moving it into `bevy_reflect?) or b) using a new-typed `Entity` as the key for events is more correct. This change is stupid simple though, and removes the offending trait bound in a way that doesn't introduce complex tech debt and does not risk changes to the internals. This change does not: - restrict our ability to implement dynamic buffered events (the main improvement over bevyengine#17317) - there's still a fair bit of work to do, but this is a step in the right direction - limit our ability to store event metadata on entities in the future - make it harder for users to work with types that are both events and components (just add the derive / trait bound) ## Migration Guide The `Event` trait no longer requires the `Component` trait. If you were relying on this behavior, change your trait bounds from `Event` to `Event + Component`. If you also want your `Event` type to implement `Component`, add a derive. --------- Co-authored-by: Chris Russell <[email protected]>
# Objective Tiny PR to use chain() for system dependency, which is shorter/clearer
# Objective - Fix issue identified on the [Discord server](https://discord.com/channels/691052431525675048/691052431974465548/1328922812530036839) ## Solution - Implement `Clone` for `QueryIter` using the existing `QueryIter::remaining` method ## Testing - CI --- ## Showcase Users can now explicitly clone a read-only `QueryIter`: ```rust fn combinations(query: Query<&ComponentA>) { let mut iter = query.iter(); while let Some(a) = iter.next() { // Can now clone rather than use remaining for b in iter.clone() { // Check every combination (a, b) } } } ``` ## Notes This doesn't add any new functionality outside the context of generic code (e.g., `T: Iterator<...> + Clone`), it's mostly for discoverability. Users are more likely to be familiar with `Clone::clone` than they are with the methods on `QueryIter`.
# Objective While `add_looping_edges` is a helpful method for manually defining directional navigation maps, we don't always want to loop around! ## Solution Add a non-looping variant. These commits are cherrypicked from the more complex bevyengine#17247. ## Testing I've updated the `directional_navigation` example to use these changes, and verified that it works. --------- Co-authored-by: Rob Parrett <[email protected]> Co-authored-by: Benjamin Brienen <[email protected]>
# Objective The safety documentation for `Ptr::assert_unique` is incomplete. Currently it only mentions the existence of other `Ptr` instances, but it should also mention that the underlying data must be mutable and that there cannot be active references to it.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.