Release 0.13.1 #7
Merged
Conversation
This file contains 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 - There are too many `NonSendMarker` https://docs.rs/bevy/0.12.1/bevy/index.html?search=nonsendmarker - There should be only one ## Solution - Use the marker type from bevy_core in bevy_render --- ## Migration Guide - If you were using `bevy::render::view::NonSendMarker` or `bevy::render::view::window::NonSendMarker`, use `bevy::core::NonSendMarker` instead
# Objective - Fixes #11727 ## Solution - Added `Mesh::remove_indices(&mut self) -> Option<Indices>`
…aded feature is enabled (#11726) # Objective bevy_render has been set to be automatically enabled if mutlti-threaded feature is ## Solution make it conditional
# Objective - Fixes #11679 ## Solution - Added `IntoSystem::system_type_id` which returns the equivalent of `system.into_system().type_id()` without construction. This allows for getting the `TypeId` of functions (a function is an unnamed type and therefore you cannot call `TypeId::of::<apply_deferred::System>()`) - Added default implementation of `System::type_id` to ensure consistency between implementations. Some returned `Self`, while others were returning an inner value instead. This ensures consistency with `IntoSystem::system_type_id`. ## Migration Guide If you use `System::type_id()` on function systems (exclusive or not), ensure you are comparing its value to other `System::type_id()` calls, or `IntoSystem::system_type_id()`. This code wont require any changes, because `IntoSystem`'s are directly compared to each other. ```rust fn test_system() {} let type_id = test_system.type_id(); // ... // No change required assert_eq!(test_system.type_id(), type_id); ``` Likewise, this code wont, because `System`'s are directly compared. ```rust fn test_system() {} let type_id = IntoSystem::into_system(test_system).type_id(); // ... // No change required assert_eq!(IntoSystem::into_system(test_system).type_id(), type_id); ``` The below _does_ require a change, since you're comparing a `System` type to a `IntoSystem` type. ```rust fn test_system() {} // Before assert_eq!(test_system.type_id(), IntoSystem::into_system(test_system).type_id()); // After assert_eq!(test_system.system_type_id(), IntoSystem::into_system(test_system).type_id()); ```
# Objective Includes the UI node size as a parameter to the UiMaterial shader, useful for SDF-based rendering, aspect ratio correction and other use cases. Fixes #11392 ## Solution Added the node size to the UiMaterial vertex shader params and also to the data that is passed to the fragment shader. ## Migration Guide This change should be backwards compatible, using the new field is optional. Note to reviewers: render pipelines are a bit outside my comfort zone, so please make sure I haven't made any mistakes. --------- Co-authored-by: Rob Parrett <robparrett@gmail.com>
# Objective During my exploratory work on the remote editor, I found a couple of types that were either not registered, or that were missing `ReflectDefault`. ## Solution - Added registration and `ReflectDefault` where applicable - (Drive by fix) Moved `Option<f32>` registration to `bevy_core` instead of `bevy_ui`, along with similar types. --- ## Changelog - Fixed: Registered `FogSettings`, `FogFalloff`, `ParallaxMappingMethod`, `OpaqueRendererMethod` structs for reflection - Fixed: Registered `ReflectDefault` trait for `ColorGrading` and `CascadeShadowConfig` structs
# Objective - The exported hashtypes are just re-exports from hashbrown, we want to drop that dependency and (in the future) let the user import their own choice. - Fixes #11717 ## Solution - Adding a deprecated tag on the re-exports, so in future releases these can be safely removed.
# Objective Split up from #11007, fixing most of the remaining work for #10569. Implement `Meshable` for `Cuboid`, `Sphere`, `Cylinder`, `Capsule`, `Torus`, and `Plane3d`. This covers all shapes that Bevy has mesh structs for in `bevy_render::mesh::shapes`. `Cone` and `ConicalFrustum` are new shapes, so I can add them in a follow-up, or I could just add them here directly if that's preferrable. ## Solution Implement `Meshable` for `Cuboid`, `Sphere`, `Cylinder`, `Capsule`, `Torus`, and `Plane3d`. The logic is mostly just a copy of the the existing `bevy_render` shapes, but `Plane3d` has a configurable surface normal that affects the orientation. Some property names have also been changed to be more consistent. The default values differ from the old shapes to make them a bit more logical: - Spheres now have a radius of 0.5 instead of 1.0. The default capsule is equivalent to the default cylinder with the sphere's halves glued on. - The inner and outer radius of the torus are now 0.5 and 1.0 instead of 0.5 and 1.5 (i.e. the new minor and major radii are 0.25 and 0.75). It's double the width of the default cuboid, half of its height, and the default sphere matches the size of the hole. - `Cuboid` is 1x1x1 by default unlike the dreaded `Box` which is 2x1x1. Before, with "old" shapes:  Now, with primitive meshing:  I only changed the `3d_shapes` example to use primitives for now. I can change them all in this PR or a follow-up though, whichever way is preferrable. ### Sphere API Spheres have had separate `Icosphere` and `UVSphere` structs, but with primitives we only have one `Sphere`. We need to handle this with builders: ```rust // Existing structs let ico = Mesh::try_from(Icophere::default()).unwrap(); let uv = Mesh::from(UVSphere::default()); // Primitives let ico = Sphere::default().mesh().ico(5).unwrap(); let uv = Sphere::default().mesh().uv(32, 18); ``` We could add methods on `Sphere` directly to skip calling `.mesh()`. I also added a `SphereKind` enum that can be used with the `kind` method: ```rust let ico = Sphere::default() .mesh() .kind(SphereKind::Ico { subdivisions: 8 }) .build(); ``` The default mesh for a `Sphere` is an icosphere with 5 subdivisions (like the default `Icosphere`). --- ## Changelog - Implement `Meshable` and `Default` for `Cuboid`, `Sphere`, `Cylinder`, `Capsule`, `Torus`, and `Plane3d` - Use primitives in `3d_shapes` example --------- Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
# Objective
Bevy could benefit from *irradiance volumes*, also known as *voxel
global illumination* or simply as light probes (though this term is not
preferred, as multiple techniques can be called light probes).
Irradiance volumes are a form of baked global illumination; they work by
sampling the light at the centers of each voxel within a cuboid. At
runtime, the voxels surrounding the fragment center are sampled and
interpolated to produce indirect diffuse illumination.
## Solution
This is divided into two sections. The first is copied and pasted from
the irradiance volume module documentation and describes the technique.
The second part consists of notes on the implementation.
### Overview
An *irradiance volume* is a cuboid voxel region consisting of
regularly-spaced precomputed samples of diffuse indirect light. They're
ideal if you have a dynamic object such as a character that can move
about
static non-moving geometry such as a level in a game, and you want that
dynamic object to be affected by the light bouncing off that static
geometry.
To use irradiance volumes, you need to precompute, or *bake*, the
indirect
light in your scene. Bevy doesn't currently come with a way to do this.
Fortunately, [Blender] provides a [baking tool] as part of the Eevee
renderer, and its irradiance volumes are compatible with those used by
Bevy.
The [`bevy-baked-gi`] project provides a tool, `export-blender-gi`, that
can
extract the baked irradiance volumes from the Blender `.blend` file and
package them up into a `.ktx2` texture for use by the engine. See the
documentation in the `bevy-baked-gi` project for more details as to this
workflow.
Like all light probes in Bevy, irradiance volumes are 1×1×1 cubes that
can
be arbitrarily scaled, rotated, and positioned in a scene with the
[`bevy_transform::components::Transform`] component. The 3D voxel grid
will
be stretched to fill the interior of the cube, and the illumination from
the
irradiance volume will apply to all fragments within that bounding
region.
Bevy's irradiance volumes are based on Valve's [*ambient cubes*] as used
in
*Half-Life 2* ([Mitchell 2006], slide 27). These encode a single color
of
light from the six 3D cardinal directions and blend the sides together
according to the surface normal.
The primary reason for choosing ambient cubes is to match Blender, so
that
its Eevee renderer can be used for baking. However, they also have some
advantages over the common second-order spherical harmonics approach:
ambient cubes don't suffer from ringing artifacts, they are smaller (6
colors for ambient cubes as opposed to 9 for spherical harmonics), and
evaluation is faster. A smaller basis allows for a denser grid of voxels
with the same storage requirements.
If you wish to use a tool other than `export-blender-gi` to produce the
irradiance volumes, you'll need to pack the irradiance volumes in the
following format. The irradiance volume of resolution *(Rx, Ry, Rz)* is
expected to be a 3D texture of dimensions *(Rx, 2Ry, 3Rz)*. The
unnormalized
texture coordinate *(s, t, p)* of the voxel at coordinate *(x, y, z)*
with
side *S* ∈ *{-X, +X, -Y, +Y, -Z, +Z}* is as follows:
```text
s = x
t = y + ⎰ 0 if S ∈ {-X, -Y, -Z}
⎱ Ry if S ∈ {+X, +Y, +Z}
⎧ 0 if S ∈ {-X, +X}
p = z + ⎨ Rz if S ∈ {-Y, +Y}
⎩ 2Rz if S ∈ {-Z, +Z}
```
Visually, in a left-handed coordinate system with Y up, viewed from the
right, the 3D texture looks like a stacked series of voxel grids, one
for
each cube side, in this order:
| **+X** | **+Y** | **+Z** |
| ------ | ------ | ------ |
| **-X** | **-Y** | **-Z** |
A terminology note: Other engines may refer to irradiance volumes as
*voxel
global illumination*, *VXGI*, or simply as *light probes*. Sometimes
*light
probe* refers to what Bevy calls a reflection probe. In Bevy, *light
probe*
is a generic term that encompasses all cuboid bounding regions that
capture
indirect illumination, whether based on voxels or not.
Note that, if binding arrays aren't supported (e.g. on WebGPU or WebGL
2),
then only the closest irradiance volume to the view will be taken into
account during rendering.
[*ambient cubes*]:
https://advances.realtimerendering.com/s2006/Mitchell-ShadingInValvesSourceEngine.pdf
[Mitchell 2006]:
https://advances.realtimerendering.com/s2006/Mitchell-ShadingInValvesSourceEngine.pdf
[Blender]: http://blender.org/
[baking tool]:
https://docs.blender.org/manual/en/latest/render/eevee/render_settings/indirect_lighting.html
[`bevy-baked-gi`]: https://github.com/pcwalton/bevy-baked-gi
### Implementation notes
This patch generalizes light probes so as to reuse as much code as
possible between irradiance volumes and the existing reflection probes.
This approach was chosen because both techniques share numerous
similarities:
1. Both irradiance volumes and reflection probes are cuboid bounding
regions.
2. Both are responsible for providing baked indirect light.
3. Both techniques involve presenting a variable number of textures to
the shader from which indirect light is sampled. (In the current
implementation, this uses binding arrays.)
4. Both irradiance volumes and reflection probes require gathering and
sorting probes by distance on CPU.
5. Both techniques require the GPU to search through a list of bounding
regions.
6. Both will eventually want to have falloff so that we can smoothly
blend as objects enter and exit the probes' influence ranges. (This is
not implemented yet to keep this patch relatively small and reviewable.)
To do this, we generalize most of the methods in the reflection probes
patch #11366 to be generic over a trait, `LightProbeComponent`. This
trait is implemented by both `EnvironmentMapLight` (for reflection
probes) and `IrradianceVolume` (for irradiance volumes). Using a trait
will allow us to add more types of light probes in the future. In
particular, I highly suspect we will want real-time reflection planes
for mirrors in the future, which can be easily slotted into this
framework.
## Changelog
> This section is optional. If this was a trivial fix, or has no
externally-visible impact, you can delete this section.
### Added
* A new `IrradianceVolume` asset type is available for baked voxelized
light probes. You can bake the global illumination using Blender or
another tool of your choice and use it in Bevy to apply indirect
illumination to dynamic objects.
# Objective - System `create_surfaces` needs to happen before `prepare_windows` or we lose one frame at startup ## Solution - Specify the ordering, remove the set as it doesn't mean anything there
# Objective - Fixes #11740 ## Solution - Turned `Mesh::set_indices` into `Mesh::insert_indices` and added related methods for completeness. --- ## Changelog - Replaced `Mesh::set_indices(indices: Option<Indices>)` with `Mesh::insert_indices(indices: Indices)` - Replaced `Mesh::with_indices(indices: Option<Indices>)` with `Mesh::with_inserted_indices(indices: Indices)` and `Mesh::with_removed_indices()` mirroring the API for inserting / removing attributes. - Updated the examples and internal uses of the APIs described above. ## Migration Guide - Use `Mesh::insert_indices` or `Mesh::with_inserted_indices` instead of `Mesh::set_indices` / `Mesh::with_indices`. - If you have passed `None` to `Mesh::set_indices` or `Mesh::with_indices` you should use `Mesh::remove_indices` or `Mesh::with_removed_indices` instead. --------- Co-authored-by: François <mockersf@gmail.com>
# Objective Fix #11657 ## Solution Add a `ReflectKind` enum, add `Reflect::reflect_kind` which returns a `ReflectKind`, and add `kind` method implementions to `ReflectRef`, `ReflectMut`, and `ReflectOwned`, which returns a `ReflectKind`. I also changed `AccessError` to use this new struct instead of it's own `TypeKind` struct. --- ## Changelog - Added `ReflectKind`, an enumeration over the kinds of a reflected type without its data. - Added `Reflect::reflect_kind` (with default implementation) - Added implementation for the `kind` method on `ReflectRef`, `ReflectMut`, and `ReflectOwned` which gives their kind without any information, as a `ReflectKind`
… views. (#11751) Don't try to create a uniform buffer for light probes if there are no views. Fixes the panic on examples that have no views, such as `touch_input_events`.
# Objective - This aims to fix #11755 - After #10812 some pipeline compilation can take more time than before and all call to `get_render_pipeline` should check the result. ## Solution - Check `get_render_pipeline` call result for msaa_writeback - I checked that no other call to `get_render_pipeline` in bevy code base is missng the checking on the result.
[`ScheduleLabel`] derive macro uses "ScheduleName" as the trait name by mistake. This only affects the error message when a user tries to use the derive macro on a union type. No other code is affected.
> Follow up to #10588 > Closes #11749 (Supersedes #11756) Enable Texture slicing for the following UI nodes: - `ImageBundle` - `ButtonBundle` <img width="739" alt="Screenshot 2024-01-29 at 13 57 43" src="https://github.com/bevyengine/bevy/assets/26703856/37675681-74eb-4689-ab42-024310cf3134"> I also added a collection of `fantazy-ui-borders` from [Kenney's](www.kenney.nl) assets, with the appropriate license (CC). If it's a problem I can use the same textures as the `sprite_slice` example # Work done Added the `ImageScaleMode` component to the targetted bundles, most of the logic is directly reused from `bevy_sprite`. The only additional internal component is the UI specific `ComputedSlices`, which does the same thing as its spritee equivalent but adapted to UI code. Again the slicing is not compatible with `TextureAtlas`, it's something I need to tackle more deeply in the future # Fixes * [x] I noticed that `TextureSlicer::compute_slices` could infinitely loop if the border was larger that the image half extents, now an error is triggered and the texture will fallback to being stretched * [x] I noticed that when using small textures with very small *tiling* options we could generate hundred of thousands of slices. Now I set a minimum size of 1 pixel per slice, which is already ridiculously small, and a warning will be sent at runtime when slice count goes above 1000 * [x] Sprite slicing with `flip_x` or `flip_y` would give incorrect results, correct flipping is now supported to both sprites and ui image nodes thanks to @odecay observation # GPU Alternative I create a separate branch attempting to implementing 9 slicing and tiling directly through the `ui.wgsl` fragment shader. It works but requires sending more data to the GPU: - slice border - tiling factors And more importantly, the actual quad *scale* which is hard to put in the shader with the current code, so that would be for a later iteration
…ocs (#11769) Several of the types that are used for both components and resources only mention components in their description. Fixes this.
# Objective - Try not to drop the render world on the render thread, and drop the main world after the render world. - The render world has a drop check that will panic if it is dropped off the main thread. ## Solution - Keep track of where the render world is and wait for it to come back when the channel resource is dropped. --- ## Changelog - Wait for the render world when the main world is dropped. ## Migration Guide - If you were using the pipelined rendering channels, `MainToRenderAppSender` and `RenderToMainAppReceiver`, they have been combined into the single resource `RenderAppChannels`. --------- Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com> Co-authored-by: Friz64 <friz64@protonmail.com>
# Objective #11431 and #11688 implemented meshing support for Bevy's new geometric primitives. The next step is to deprecate the shapes in `bevy_render::mesh::shape` and to later remove them completely for 0.14. ## Solution Deprecate the shapes and reduce code duplication by utilizing the primitive meshing API for the old shapes where possible. Note that some shapes have behavior that can't be exactly reproduced with the new primitives yet: - `Box` is more of an AABB with min/max extents - `Plane` supports a subdivision count - `Quad` has a `flipped` property These types have not been changed to utilize the new primitives yet. --- ## Changelog - Deprecated all shapes in `bevy_render::mesh::shape` - Changed all examples to use new primitives for meshing ## Migration Guide Bevy has previously used rendering-specific types like `UVSphere` and `Quad` for primitive mesh shapes. These have now been deprecated to use the geometric primitives newly introduced in version 0.13. Some examples: ```rust let before = meshes.add(shape::Box::new(5.0, 0.15, 5.0)); let after = meshes.add(Cuboid::new(5.0, 0.15, 5.0)); let before = meshes.add(shape::Quad::default()); let after = meshes.add(Rectangle::default()); let before = meshes.add(shape::Plane::from_size(5.0)); // The surface normal can now also be specified when using `new` let after = meshes.add(Plane3d::default().mesh().size(5.0, 5.0)); let before = meshes.add( Mesh::try_from(shape::Icosphere { radius: 0.5, subdivisions: 5, }) .unwrap(), ); let after = meshes.add(Sphere::new(0.5).mesh().ico(5).unwrap()); ```
# Objective While profiling around to validate the results of #9172, I noticed that `present_frames` can take a significant amount of time. Digging into the cause, it seems like we're creating a new `QueryState` from scratch every frame. This involves scanning the entire World's metadata instead of just updating its view of the world. ## Solution Use a `SystemState` argument to cache the `QueryState` to avoid this construction cost. ## Performance Against `many_foxes`, this seems to cut the time spent in `present_frames` by nearly almost 2x. Yellow is this PR, red is main. 
Bumps [peter-evans/create-pull-request](https://github.com/peter-evans/create-pull-request) from 5 to 6. <details> <summary>Release notes</summary> <p><em>Sourced from <a href="https://github.com/peter-evans/create-pull-request/releases">peter-evans/create-pull-request's releases</a>.</em></p> <blockquote> <h2>Create Pull Request v6.0.0</h2> <h2>Behaviour changes</h2> <ul> <li>The default values for <code>author</code> and <code>committer</code> have changed. See "What's new" below for details. If you are overriding the default values you will not be affected by this change.</li> <li>On completion, the action now removes the temporary git remote configuration it adds when using <code>push-to-fork</code>. This should not affect you unless you were using the temporary configuration for some other purpose after the action completes.</li> </ul> <h2>What's new</h2> <ul> <li>Updated runtime to Node.js 20 <ul> <li>The action now requires a minimum version of <a href="https://github.com/actions/runner/releases/tag/v2.308.0">v2.308.0</a> for the Actions runner. Update self-hosted runners to v2.308.0 or later to ensure compatibility.</li> </ul> </li> <li>The default value for <code>author</code> has been changed to <code>${{ github.actor }} <${{ github.actor_id }}+${{ github.actor }}@users.noreply.github.com></code>. The change adds the <code>${{ github.actor_id }}+</code> prefix to the email address to align with GitHub's standard format for the author email address.</li> <li>The default value for <code>committer</code> has been changed to <code>github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com></code>. This is to align with the default GitHub Actions bot user account.</li> <li>Adds input <code>git-token</code>, the <a href="https://docs.github.com/en/github/authenticating-to-github/creating-a-personal-access-token">Personal Access Token (PAT)</a> that the action will use for git operations. This input defaults to the value of <code>token</code>. Use this input if you would like the action to use a different token for git operations than the one used for the GitHub API.</li> <li><code>push-to-fork</code> now supports pushing to sibling repositories in the same network.</li> <li>Previously, when using <code>push-to-fork</code>, the action did not remove temporary git remote configuration it adds during execution. This has been fixed and the configuration is now removed when the action completes.</li> <li>If the pull request body is truncated due to exceeding the maximum length, the action will now suffix the body with the message "...<em>[Pull request body truncated]</em>" to indicate that the body has been truncated.</li> <li>The action now uses <code>--unshallow</code> only when necessary, rather than as a default argument of <code>git fetch</code>. This should improve performance, particularly for large git repositories with extensive commit history.</li> <li>The action can now be executed on one GitHub server and create pull requests on a <em>different</em> GitHub server. Server products include GitHub hosted (github.com), GitHub Enterprise Server (GHES), and GitHub Enterprise Cloud (GHEC). For example, the action can be executed on GitHub hosted and create pull requests on a GHES or GHEC instance.</li> </ul> <h2>What's Changed</h2> <ul> <li>Update distribution by <a href="https://github.com/actions-bot"><code>@actions-bot</code></a> in <a href="https://redirect.github.com/peter-evans/create-pull-request/pull/2086">peter-evans/create-pull-request#2086</a></li> <li>fix crazy-max/ghaction-import-gp parameters by <a href="https://github.com/fharper"><code>@fharper</code></a> in <a href="https://redirect.github.com/peter-evans/create-pull-request/pull/2177">peter-evans/create-pull-request#2177</a></li> <li>Update distribution by <a href="https://github.com/actions-bot"><code>@actions-bot</code></a> in <a href="https://redirect.github.com/peter-evans/create-pull-request/pull/2364">peter-evans/create-pull-request#2364</a></li> <li>Use checkout v4 by <a href="https://github.com/okuramasafumi"><code>@okuramasafumi</code></a> in <a href="https://redirect.github.com/peter-evans/create-pull-request/pull/2521">peter-evans/create-pull-request#2521</a></li> <li>Note about <code>delete-branch</code> by <a href="https://github.com/dezren39"><code>@dezren39</code></a> in <a href="https://redirect.github.com/peter-evans/create-pull-request/pull/2631">peter-evans/create-pull-request#2631</a></li> <li>98 dependency updates by <a href="https://github.com/dependabot"><code>@dependabot</code></a></li> </ul> <h2>New Contributors</h2> <ul> <li><a href="https://github.com/fharper"><code>@fharper</code></a> made their first contribution in <a href="https://redirect.github.com/peter-evans/create-pull-request/pull/2177">peter-evans/create-pull-request#2177</a></li> <li><a href="https://github.com/okuramasafumi"><code>@okuramasafumi</code></a> made their first contribution in <a href="https://redirect.github.com/peter-evans/create-pull-request/pull/2521">peter-evans/create-pull-request#2521</a></li> <li><a href="https://github.com/dezren39"><code>@dezren39</code></a> made their first contribution in <a href="https://redirect.github.com/peter-evans/create-pull-request/pull/2631">peter-evans/create-pull-request#2631</a></li> </ul> <p><strong>Full Changelog</strong>: <a href="https://github.com/peter-evans/create-pull-request/compare/v5.0.2...v6.0.0">https://github.com/peter-evans/create-pull-request/compare/v5.0.2...v6.0.0</a></p> <h2>Create Pull Request v5.0.2</h2> <p>⚙️ Fixes an issue that occurs when using <code>push-to-fork</code> and both base and head repositories are in the same org/user account.</p> <h2>What's Changed</h2> <ul> <li>fix: specify head repo by <a href="https://github.com/peter-evans"><code>@peter-evans</code></a> in <a href="https://redirect.github.com/peter-evans/create-pull-request/pull/2044">peter-evans/create-pull-request#2044</a></li> <li>20 dependency updates by <a href="https://github.com/dependabot"><code>@dependabot</code></a></li> </ul> <p><strong>Full Changelog</strong>: <a href="https://github.com/peter-evans/create-pull-request/compare/v5.0.1...v5.0.2">https://github.com/peter-evans/create-pull-request/compare/v5.0.1...v5.0.2</a></p> <h2>Create Pull Request v5.0.1</h2> <h2>What's Changed</h2> <ul> <li>fix: truncate body if exceeds max length by <a href="https://github.com/peter-evans"><code>@peter-evans</code></a> in <a href="https://redirect.github.com/peter-evans/create-pull-request/pull/1915">peter-evans/create-pull-request#1915</a></li> <li>12 dependency updates by <a href="https://github.com/dependabot"><code>@dependabot</code></a></li> </ul> <p><strong>Full Changelog</strong>: <a href="https://github.com/peter-evans/create-pull-request/compare/v5.0.0...v5.0.1">https://github.com/peter-evans/create-pull-request/compare/v5.0.0...v5.0.1</a></p> </blockquote> </details> <details> <summary>Commits</summary> <ul> <li><a href="https://github.com/peter-evans/create-pull-request/commit/b1ddad2c994a25fbc81a28b3ec0e368bb2021c50"><code>b1ddad2</code></a> feat: v6 (<a href="https://redirect.github.com/peter-evans/create-pull-request/issues/2717">#2717</a>)</li> <li><a href="https://github.com/peter-evans/create-pull-request/commit/bb809027fda03cc267431a7d36a88148eb9f3846"><code>bb80902</code></a> build(deps-dev): bump <code>@types/node</code> from 18.19.8 to 18.19.10 (<a href="https://redirect.github.com/peter-evans/create-pull-request/issues/2712">#2712</a>)</li> <li><a href="https://github.com/peter-evans/create-pull-request/commit/e0037d470cdeb1c8133acfba89af08639bb69eb3"><code>e0037d4</code></a> build(deps): bump peter-evans/create-or-update-comment from 3 to 4 (<a href="https://redirect.github.com/peter-evans/create-pull-request/issues/2702">#2702</a>)</li> <li><a href="https://github.com/peter-evans/create-pull-request/commit/94b1f99e3a73880074d0e669c3b69d376cc8ceae"><code>94b1f99</code></a> build(deps): bump peter-evans/find-comment from 2 to 3 (<a href="https://redirect.github.com/peter-evans/create-pull-request/issues/2703">#2703</a>)</li> <li><a href="https://github.com/peter-evans/create-pull-request/commit/69c27eaf4a14a67b5362a51e681f83d3d5e0f96b"><code>69c27ea</code></a> build(deps-dev): bump ts-jest from 29.1.1 to 29.1.2 (<a href="https://redirect.github.com/peter-evans/create-pull-request/issues/2685">#2685</a>)</li> <li><a href="https://github.com/peter-evans/create-pull-request/commit/7ea722a0f6286a45eb3005280d83575a74bc8fef"><code>7ea722a</code></a> build(deps-dev): bump prettier from 3.2.2 to 3.2.4 (<a href="https://redirect.github.com/peter-evans/create-pull-request/issues/2684">#2684</a>)</li> <li><a href="https://github.com/peter-evans/create-pull-request/commit/5ee839affd4c87811108724370a2819a40e2e5d3"><code>5ee839a</code></a> build(deps-dev): bump <code>@types/node</code> from 18.19.7 to 18.19.8 (<a href="https://redirect.github.com/peter-evans/create-pull-request/issues/2683">#2683</a>)</li> <li><a href="https://github.com/peter-evans/create-pull-request/commit/60fc256c678e6ed78d0d42e09675c9beba09cb94"><code>60fc256</code></a> build(deps-dev): bump eslint-plugin-prettier from 5.1.2 to 5.1.3 (<a href="https://redirect.github.com/peter-evans/create-pull-request/issues/2660">#2660</a>)</li> <li><a href="https://github.com/peter-evans/create-pull-request/commit/0c677233614c017442253060c74fd2cb7ff349fc"><code>0c67723</code></a> build(deps-dev): bump <code>@types/node</code> from 18.19.5 to 18.19.7 (<a href="https://redirect.github.com/peter-evans/create-pull-request/issues/2661">#2661</a>)</li> <li><a href="https://github.com/peter-evans/create-pull-request/commit/4e288e851b95bd1362e281a255094fcc47ada675"><code>4e288e8</code></a> build(deps-dev): bump prettier from 3.1.1 to 3.2.2 (<a href="https://redirect.github.com/peter-evans/create-pull-request/issues/2659">#2659</a>)</li> <li>Additional commits viewable in <a href="https://github.com/peter-evans/create-pull-request/compare/v5...v6">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 - Encoding many GPU commands (such as in a renderpass with many draws, such as the main opaque pass) onto a `wgpu::CommandEncoder` is very expensive, and takes a long time. - To improve performance, we want to perform the command encoding for these heavy passes in parallel. ## Solution - `RenderContext` can now queue up "command buffer generation tasks" which are closures that will generate a command buffer when called. - When finalizing the render context to produce the final list of command buffers, these tasks are run in parallel on the `ComputeTaskPool` to produce their corresponding command buffers. - The general idea is that the node graph will run in serial, but in a node, instead of doing rendering work, you can add tasks to do render work in parallel with other node's tasks that get ran at the end of the graph execution. ## Nodes Parallelized - `MainOpaquePass3dNode` - `PrepassNode` - `DeferredGBufferPrepassNode` - `ShadowPassNode` (One task per view) ## Future Work - For large number of draws calls, might be worth further subdividing passes into 2+ tasks. - Extend this to UI, 2d, transparent, and transmissive nodes? - Needs testing - small command buffers are inefficient - it may be worth reverting to the serial command encoder usage for render phases with few items. - All "serial" (traditional) rendering work must finish before parallel rendering tasks (the new stuff) can start to run. - There is still only one submission to the graphics queue at the end of the graph execution. There is still no ability to submit work earlier. ## Performance Improvement Thanks to @Elabajaba for testing on Bistro.  TLDR: Without shadow mapping, this PR has no impact. _With_ shadow mapping, this PR gives **~40 more fps** than main. --- ## Changelog - `MainOpaquePass3dNode`, `PrepassNode`, `DeferredGBufferPrepassNode`, and each shadow map within `ShadowPassNode` are now encoded in parallel, giving _greatly_ increased CPU performance, mainly when shadow mapping is enabled. - Does not work on WASM or AMD+Windows+Vulkan. - Added `RenderContext::add_command_buffer_generation_task()`. - `RenderContext::new()` now takes adapter info - Some render graph and Node related types and methods now have additional lifetime constraints. ## Migration Guide `RenderContext::new()` now takes adapter info - Some render graph and Node related types and methods now have additional lifetime constraints. --------- Co-authored-by: Elabajaba <Elabajaba@users.noreply.github.com> Co-authored-by: François <mockersf@gmail.com>
# Objective The screenshots generated by the `screenshot` example need to be removed manually before commiting changes. ## Solution `.gitignore` the screenshots generated by the `screenshot` example. I also added the `**/` prefix so the screenshots get ignored regardless of whether of where the example is run from.
> Follow up to #11600 and #10588 @mockersf expressed some [valid concerns](#11600 (comment)) about the current system this PR attempts to fix: The `ComputedTextureSlices` reacts to asset change in both `bevy_sprite` and `bevy_ui`, meaning that if the `ImageScaleMode` is inserted by default in the bundles, we will iterate through most 2d items every time an asset is updated. # Solution - `ImageScaleMode` only has two variants: `Sliced` and `Tiled`. I removed the `Stretched` default - `ImageScaleMode` is no longer part of any bundle, but the relevant bundles explain that this additional component can be inserted This way, the *absence* of `ImageScaleMode` means the image will be stretched, and its *presence* will include the entity to the various slicing systems Optional components in bundles would make this more straigthfoward # Additional work Should I add new bundles with the `ImageScaleMode` component ?
# Objective `bevy_utils` only requires aHash 0.8.3, which is broken on Rust 1.7.6: ``` error: could not compile `ahash` (lib) due to 1 previous error error[E0635]: unknown feature `stdsimd` ``` See tkaitchuck/aHash#200 This is fixed in aHash 0.8.7, so require at least that version (Cargo.lock is already up to date).
This fixes a `FIXME` in `extract_meshes` and results in a performance improvement. As a result of this change, meshes in the render world might not be attached to entities anymore. Therefore, the `entity` parameter to `RenderCommand::render()` is now wrapped in an `Option`. Most applications that use the render app's ECS can simply unwrap the `Option`. Note that for now sprites, gizmos, and UI elements still use the render world as usual. ## Migration guide * For efficiency reasons, some meshes in the render world may not have corresponding `Entity` IDs anymore. As a result, the `entity` parameter to `RenderCommand::render()` is now wrapped in an `Option`. Custom rendering code may need to be updated to handle the case in which no `Entity` exists for an object that is to be rendered.
…11795) # Objective I want to keep track of despawned entities. I am aware of [`RemovedComponents`](https://docs.rs/bevy/0.12.1/bevy/ecs/prelude/struct.RemovedComponents.html). However, the docs don't explicitly mention that despawned entities are also included in this event iterator. I searched through the bevy tests to find `removal_tracking` in `crates/bevy_ecs/src/system/mod.rs` that confirmed the behavior: ```rust ... assert_eq!( removed_i32.read().collect::<Vec<_>>(), &[despawned.0], "despawning causes the correct entity to show up in the 'RemovedComponent' system parameter." ); ... ``` ## Solution - Explicitly mention this behavior in docs.
# Objective It would be useful to be able to inspect a `QueryState`'s accesses so we can detect when the data it accesses changes without having to iterate it. However there are two things preventing this: * These accesses are unnecessarily encapsulated. * `Has<T>` indirectly accesses `T`, but does not register it. ## Solution * Expose accesses and matches used by `QueryState`. * Add the notion of "archetypal" accesses, which are not accessed directly, but whose presence in an archetype affects a query result. --------- Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
…12052) This PR closes #11978 # Objective Fix rendering on iOS Simulators. iOS Simulator doesn't support the capability CUBE_ARRAY_TEXTURES, since 0.13 this started to make iOS Simulator not render anything with the following message being outputted: ``` 2024-02-19T14:59:34.896266Z ERROR bevy_render::render_resource::pipeline_cache: failed to create shader module: Validation Error Caused by: In Device::create_shader_module Shader validation error: Type [40] '' is invalid Capability Capabilities(CUBE_ARRAY_TEXTURES) is required ``` ## Solution - Split up NO_ARRAY_TEXTURES_SUPPORT into both NO_ARRAY_TEXTURES_SUPPORT and NO_CUBE_ARRAY_TEXTURES_SUPPORT and correctly apply NO_ARRAY_TEXTURES_SUPPORT for iOS Simulator using the cfg flag introduced in #10178. --- ## Changelog ### Fixed - Rendering on iOS Simulator due to missing CUBE_ARRAY_TEXTURES support. --------- Co-authored-by: Sam Pettersson <sam.pettersson@geoguessr.com>
# Objective - Some properties of public types are private but sometimes it's useful to be able to set those ## Solution - Make more stuff pub --- ## Changelog - `MaterialBindGroupId` internal id is now pub and added a new() constructor - `ExtractedPointLight` and `ExtractedDirectionalLight` properties are now all pub --------- Co-authored-by: James Liu <contact@jamessliu.com>
# Objective - Fixes #11977 - user defined shaders don't work in wasm - After investigation, it won't work if the shader is not yet available when compiling the pipeline on all platforms, for example if you load many assets ## Solution - Set the pipeline state to queued when it errs waiting for the shader so that it's retried
… errors. (#12046) # Objective Improve code quality and prevent bugs. ## Solution I removed the unnecessary wildcards from `<LogPlugin as Plugin>::build`. I also changed the warnings that would occur if the subscriber/logger was already set into errors.
# Objective
Fixes Skyboxes on WebGL, which broke in Bevy 0.13 due to the addition of
the `brightness` uniform, when previously the skybox pipeline only had
view and global uniforms.
```ignore
panicked at ~/.cargo/registry/src/index.crates.io-6f17d22bba15001f/wgpu-0.19.1/src/backend/wgpu_core.rs:3009:5:
wgpu error: Validation Error
Caused by:
In Device::create_render_pipeline
note: label = `skybox_pipeline`
In the provided shader, the type given for group 0 binding 3 has a size of 4. As the device does not support `DownlevelFlags::BUFFER_BINDINGS_NOT_16_BYTE_ALIGNED`, the type must have a size that is a multiple of 16 bytes.
```
It would be nice if this could be backported to a 0.13.1 patch as well
if possible. I'm needing to rely on my own fork for now.
## Solution
Similar to the Globals uniform solution here:
https://github.com/bevyengine/bevy/blob/d31de3f1398080661a83a04dcbdd31a7ee9fa76e/crates/bevy_render/src/globals.rs#L59-L60
I've added 3 conditional fields to `SkyboxUniforms`.
# Objective Since #9822, `SimpleExecutor` panics when an automatic sync point is inserted: ```rust let mut sched = Schedule::default(); sched.set_executor_kind(ExecutorKind::Simple); sched.add_systems((|_: Commands| (), || ()).chain()); sched.run(&mut World::new()); ``` ``` System's param_state was not found. Did you forget to initialize this system before running it? note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace Encountered a panic in system `bevy_ecs::schedule::executor::apply_deferred`! ``` ## Solution Don't try to run the `apply_deferred` system.
# Objective - Fixes #12057 ## Solution - Add a note about memory management in Wasm
# Objective - Bevy fails to change screen orientation on iOS ``` Main Thread Checker: UI API called on a background thread: -[UIView layer] PID: 37669, TID: 13872050, Thread name: Compute Task Pool (1), Queue name: com.apple.root.default-qos.overcommit, QoS: 0 Backtrace: 4 bevy_mobile_example 0x0000000102cf92b8 _ZN60_$LT$$LP$$RP$$u20$as$u20$objc..message..MessageArguments$GT$6invoke17h8944e3d8ee34f15fE + 64 5 bevy_mobile_example 0x0000000102c46358 _ZN4objc7message8platform15send_unverified17h667844cebe2d7931E + 132 6 bevy_mobile_example 0x0000000102bcbd6c _ZN8wgpu_hal5metal7surface100_$LT$impl$u20$wgpu_hal..Surface$LT$wgpu_hal..metal..Api$GT$$u20$for$u20$wgpu_hal..metal..Surface$GT$9configure17h8a6af0f24cec1328E + 1548 7 bevy_mobile_example 0x000000010279be50 _ZN9wgpu_core6device6global52_$LT$impl$u20$wgpu_core..global..Global$LT$G$GT$$GT$17surface_configure17h52709bbb3b3f0ff1E + 2792 8 bevy_mobile_example 0x000000010287aacc _ZN84_$LT$wgpu..backend..wgpu_core..ContextWgpuCore$u20$as$u20$wgpu..context..Context$GT$17surface_configure17h54077b9f040286a4E + 508 9 bevy_mobile_example 0x00000001028904b4 _ZN47_$LT$T$u20$as$u20$wgpu..context..DynContext$GT$17surface_configure17hfd6a0ac5a67a8f02E + 256 10 bevy_mobile_example 0x00000001028a1870 _ZN4wgpu7Surface9configure17h97bf7dbd54220473E + 148 11 bevy_mobile_example 0x0000000101fdc7cc _ZN11bevy_render8renderer13render_device12RenderDevice17configure_surface17h6853eab840b53e07E + 56 12 bevy_mobile_example 0x000000010228eb64 _ZN11bevy_render4view6window15prepare_windows17hf6f8b3c93ba189b8E + 3248 13 bevy_mobile_example 0x0000000102169eb8 _ZN4core3ops8function5FnMut8call_mut17h53ae762930afec98E + 192 14 bevy_mobile_example 0x0000000101e46a80 _ZN4core3ops8function5impls79_$LT$impl$u20$core..ops..function..FnMut$LT$A$GT$$u20$for$u20$$RF$mut$u20$F$GT$8call_mut17h5789c37c5983ce4cE + 208 15 bevy_mobile_example 0x0000000101e936e4 _ZN152_$LT$Func$u20$as$u20$bevy_ecs..system..function_system..SystemParamFunction$LT$fn$LP$F0$C$F1$C$F2$C$F3$C$F4$C$F5$C$F6$C$F7$RP$$u20$.$GT$$u20$Out$GT$$GT$3run10call_inner17h4ea44d3456146151E + 220 16 bevy_mobile_example 0x0000000101e4683c _ZN152_$LT$Func$u20$as$u20$bevy_ecs..system..function_system..SystemParamFunction$LT$fn$LP$F0$C$F1$C$F2$C$F3$C$F4$C$F5$C$F6$C$F7$RP$$u20$.$GT$$u20$Out$GT$$GT$3run17h6515ba9e61bb4d59E + 204 17 bevy_mobile_example 0x0000000101e7f99c _ZN120_$LT$bevy_ecs..system..function_system..FunctionSystem$LT$Marker$C$F$GT$$u20$as$u20$bevy_ecs..system..system..System$GT$10run_unsafe17h78999ea2add1da26E + 212 18 bevy_mobile_example 0x0000000103b4ef60 _ZN8bevy_ecs8schedule8executor14multi_threaded21MultiThreadedExecutor17spawn_system_task28_$u7b$$u7b$closure$u7d$$u7d$28_$u7b$$u7b$closure$u7d$$u7d$17hb2572f7968d8618eE + 48 19 bevy_mobile_example 0x0000000103b5bc9c _ZN4core3ops8function6FnOnce9call_once17h4cfa9d5c488566d4E + 16 20 bevy_mobile_example 0x0000000103b2d58c _ZN115_$LT$core..panic..unwind_safe..AssertUnwindSafe$LT$F$GT$$u20$as$u20$core..ops..function..FnOnce$LT$$LP$$RP$$GT$$GT$9call_once17he61d5557ff370a2cE + 40 21 bevy_mobile_example 0x0000000103b34548 _ZN3std9panicking3try7do_call17hb9ad087e1a06eb39E + 72 22 bevy_mobile_example 0x0000000103b351bc __rust_try + 32 23 bevy_mobile_example 0x0000000103b33a30 _ZN3std9panicking3try17hdebf82084f4342b0E + 76 24 bevy_mobile_example 0x0000000103c4aedc _ZN3std5panic12catch_unwind17h7e60b22a0a18032eE + 12 25 bevy_mobile_example 0x0000000103b4ea78 _ZN8bevy_ecs8schedule8executor14multi_threaded21MultiThreadedExecutor17spawn_system_task28_$u7b$$u7b$closure$u7d$$u7d$17h1af950387501b795E + 148 26 bevy_mobile_example 0x0000000103b2cfa0 _ZN100_$LT$core..panic..unwind_safe..AssertUnwindSafe$LT$F$GT$$u20$as$u20$core..future..future..Future$GT$4poll17h1258e4bf3dbe2fd8E + 48 ``` ## Solution - run surface configuration on the main thread on iOS ## Migration Guide System `need_new_surfaces` has been renamed `need_surface_configuration` and now also configure the surfaces on window creation or resizing
This PR unpins `web-sys` so that unrelated projects that have `bevy_render` in their workspace can finally update their `web-sys`. More details in and fixes #12246. * Update `wgpu` from 0.19.1 to 0.19.3. * Remove the `web-sys` pin. * Update docs and wasm helper to remove the now-stale `--cfg=web_sys_unstable_apis` Rust flag. --- Updated `wgpu` to v0.19.3 and removed `web-sys` pin.
Hi, this is a minimal implementation of #12159. I wasn't sure if the `EventLoopProxy` should be wrapped somewhat to make it more explicit. Minimal implementation of #12159 When using `UpdateMode::Reactive` it is currently not possible to request a redraw when a long running task is finished or an external source has new data. This makes the following possible which will then run an app update once ``` rust // EventLoopProxy is Send on most architectures // The EventLoopProxy can also be saved in a thread local for WASM or a static in other architecturecs pub fn example(proxy: NonSend<EventLoopProxy<()>>) { let clone: EventLoopProxy<()> = proxy.clone(); thread::spawn(move || { // do long work clone.send_event(()); }); } ``` By using the EventLoopProxy one can manually send events from external threads to the event loop as `UserEvent`s. This simply sets redraw_requested when a `UserEvent` is received. - Added the ability to request a redraw from an external source --------- Co-authored-by: Kellner, Robin <Robin.Kellner@vector.com>
# Objective Fixes #12126 Notably this does not appear to fix the console error spam that appears to be coming from winit, only the performance bug that occurs when tabbing out and back into the game. ## Solution The winit event loop starts out as `ControlFlow::Wait` by default. When switching to `UpdateMode::Reactive` or `UpdateMode::ReactiveLowPower`, we repeatedly update this to `ControlFlow::WaitUntil(next)`. When switching back to `UpdateMode::Continuous`, the event loop is erroneously stuck at the latest `ControlFlow::WaitUntil(next)` that was issued. I also changed how we handle `Event::NewEvents` since the `StartCause` already tells us enough information to make that decision. This came about my debugging and I left it in as an improvement.
…layout to be calculated (#12268) # Objective - Fixes #12255 Still needs confirming what the consequences are from having camera viewport nodes live on the root of the taffy tree. ## Solution To fix calculating the layouts for UI nodes we need to cleanup the children previously set whenever `TargetCamera` is updated. This also maintains a list of taffy camera nodes and cleans them up when removed. --- ## Changelog Fixed #12255 ## Migration Guide changes affect private structs/members so shouldn't need actions by engine users.
- Avoid version mismatch - When cpal updates oboe in a patch release, this breaks android support for Bevy - Use the same version of oboe as cpal by relying on it to re-export the feature
…#12355) # Objective Fixes #12353 When only `webp` was selected, `ImageLoader` would not be initialized. That is, users using `default-features = false` would need to add `png` or `bmp` or something in addition to `webp` in order to use `webp`. This was also the case for `pnm`. ## Solution Add `webp` and `pnm` to the list of features that trigger the initialization of `ImageLoader`.
- With the recent lighting changes, the default configuration in the `bloom_3d` example is less clear what bloom actually does - See [this screenshot](https://github.com/bevyengine/bevy-website/pull/1023/files/4fdb1455d5a3371d69db32b036e38731342b48de#r1494648414) for a comparison. - `bloom_3d` additionally uses a for-loop to spawn the spheres, which can be turned into `commands::spawn_batch` call. - The text is black, which is difficult to see on the gray background. - Increase emmisive values of materials. - Set text to white. Before: <img width="1392" alt="before" src="https://github.com/bevyengine/bevy/assets/59022059/757057ad-ed9f-4eed-b135-8e2032fcdeb5"> After: <img width="1392" alt="image" src="https://github.com/bevyengine/bevy/assets/59022059/3f9dc7a8-94b2-44b9-8ac3-deef1905221b"> --------- Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
# Objective fix occasional crash from commands.insert when quickly spawning and despawning skinned/morphed meshes ## Solution use `try_insert` instead of `insert`. if the entity is deleted we don't mind failing to add the `NoAutomaticBatching` marker.
# Objective Fixes #12064 ## Solution Prior to #11326, the "global physical" translation of text was rounded. After #11326, only the "offset" is being rounded. This moves things around so that the "global translation" is converted to physical pixels, rounded, and then converted back to logical pixels, which is what I believe was happening before / what the comments above describe. ## Discussion This seems to work and fix an obvious mistake in some code, but I don't fully grok the ui / text pipelines / math here. ## Before / After and test example <details> <summary>Expand Code</summary> ```rust use std::f32::consts::FRAC_PI_2; use bevy::prelude::*; use bevy_internal::window::WindowResolution; const FONT_SIZE: f32 = 25.0; const PADDING: f32 = 5.0; fn main() { App::new() .add_plugins( DefaultPlugins.set(WindowPlugin { primary_window: Some(Window { resolution: WindowResolution::default().with_scale_factor_override(1.0), ..default() }), ..default() }), //.set(ImagePlugin::default_nearest()), ) .add_systems(Startup, setup) .run(); } fn setup(mut commands: Commands, asset_server: Res<AssetServer>) { commands.spawn(Camera2dBundle::default()); let font = asset_server.load("fonts/FiraSans-Bold.ttf"); for x in [20.5, 140.0] { for i in 1..10 { text( &mut commands, font.clone(), x, (FONT_SIZE + PADDING) * i as f32, i, Quat::default(), 1.0, ); } } for x in [450.5, 700.0] { for i in 1..10 { text( &mut commands, font.clone(), x, ((FONT_SIZE * 2.0) + PADDING) * i as f32, i, Quat::default(), 2.0, ); } } for y in [400.0, 600.0] { for i in 1..10 { text( &mut commands, font.clone(), (FONT_SIZE + PADDING) * i as f32, y, i, Quat::from_rotation_z(FRAC_PI_2), 1.0, ); } } } fn text( commands: &mut Commands, font: Handle<Font>, x: f32, y: f32, i: usize, rot: Quat, scale: f32, ) { let text = (65..(65 + i)).map(|a| a as u8 as char).collect::<String>(); commands.spawn(TextBundle { style: Style { position_type: PositionType::Absolute, left: Val::Px(x), top: Val::Px(y), ..default() }, text: Text::from_section( text, TextStyle { font, font_size: FONT_SIZE, ..default() }, ), transform: Transform::from_rotation(rot).with_scale(Vec2::splat(scale).extend(1.)), ..default() }); } ``` </details> Open both images in new tabs and swap back and forth. Pay attention to the "A" and "ABCD" lines. <details> <summary>Before</summary> <img width="640" alt="main3" src="https://github.com/bevyengine/bevy/assets/200550/248d7a55-d06d-433f-80da-1914803c3551"> </details> <details> <summary>After</summary> <img width="640" alt="pr3" src="https://github.com/bevyengine/bevy/assets/200550/26a9d292-07ae-4af3-b035-e187b2529ace"> </details> --------- Co-authored-by: François Mockers <mockersf@gmail.com>
…2428) # Objective To have a user level workaround for #12237. ## Solution Workaround to the problem is described in: #12237 (comment) ## Changelog ### Changed - `CreateWindowParams` type and `create_windows` system from `bevy_winit` is now public, which allows library authors and game developers to manually trigger window creation when needed.
# Objective - Addresses #12462 - When we serialize an enum, deserialize it, then reserialize it, the correct variant should be selected. ## Solution - Change `dynamic_enum.set_variant` to `dynamic_enum.set_variant_with_index` in `EnumVisitor`
# Objective
The `example-showcase` command is failing to run.
```
cargo run --release -p example-showcase -- run --screenshot --in-ci
Updating crates.io index
Compiling example-showcase v0.14.0-dev (/Users/robparrett/src/bevy/tools/example-showcase)
Finished release [optimized] target(s) in 2.59s
Running `target/release/example-showcase run --screenshot --in-ci`
$ git apply --ignore-whitespace tools/example-showcase/remove-desktop-app-mode.patch
error: patch failed: crates/bevy_winit/src/winit_config.rs:29
error: crates/bevy_winit/src/winit_config.rs: patch does not apply
thread 'main' panicked at tools/example-showcase/src/main.rs:203:18:
called `Result::unwrap()` on an `Err` value: command exited with non-zero code `git apply --ignore-whitespace tools/example-showcase/remove-desktop-app-mode.patch`: 1
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
## Solution
Update `remove-desktop-app-mode.patch`.
fix #12344 use existing machinery in track_assets to determine if the asset is unused before firing Asset::Unused event ~~most extract functions use `AssetEvent::Removed` to schedule deletion of render world resources. `RenderAssetPlugin` was using `AssetEvent::Unused` instead. `Unused` fires when the last strong handle is dropped, even if a new one is created. `Removed` only fires when a new one is not created. as far as i can see, `Unused` is the same as `Removed` except for this "feature", and that it also fires early if all handles for a loading asset are dropped (`Removed` fires after the loading completes). note that in that case, processing based on `Loaded` won't have been done anyway. i think we should get rid of `Unused` completely, it is not currently used anywhere (except here, previously) and i think using it is probably always a mistake. i also am not sure why we keep loading assets that have been dropped while loading, we should probably drop the loader task as well and remove immediately.~~
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.
update my branch to 0.13.1