[Merged by Bors] - Make `RenderStage::Extract` run on the render world #4402

DJMcNab · 2022-04-03T15:39:07Z

Objective

Currently, the Extract RenderStage is executed on the main world, with the render world available as a resource.
However, when needing access to resources in the render world (e.g. to mutate them), the only way to do so was to get exclusive access to the whole RenderWorld resource.
This meant that effectively only one extract which wrote to resources could run at a time.
We didn't previously make Extracting writing to the world a non-happy path, even though we want to discourage that.

Solution

Move the extract stage to run on the render world.
Add the main world as a MainWorld resource.
Add an Extract SystemParam as a convenience to access a (read only) SystemParam in the main world during Extract.

Future work

It should be possible to avoid needing to use get_or_spawn for the render commands, since now the Commands' Entities matches up with the world being executed on.
We need to determine how this interacts with #3519
It's theoretically possible to remove the need for the value method on Extract. However, that requires slightly changing the SystemParam interface, which would make it more complicated. That would probably mess up the SystemState api too.

Todo

I still need to add doc comments to Extract.

Changelog

Changed

The Extract RenderStage now runs on the render world (instead of the main world as before).
You must use the Extract SystemParam to access the main world during the extract phase.
Resources on the render world can now be accessed using ResMut during extract.

Removed

Commands::spawn_and_forget. Use Commands::get_or_spawn(e).insert_bundle(bundle) instead

Migration Guide

The Extract RenderStage now runs on the render world (instead of the main world as before).
You must use the Extract SystemParam to access the main world during the extract phase. Extract takes a single type parameter, which is any system parameter (such as Res, Query etc.). It will extract this from the main world, and returns the result of this extraction when value is called on it.

For example, if previously your extract system looked like:

fn extract_clouds(mut commands: Commands, clouds: Query<Entity, With<Cloud>>) {
    for cloud in clouds.iter() {
        commands.get_or_spawn(cloud).insert(Cloud);
    }
}

the new version would be:

fn extract_clouds(mut commands: Commands, mut clouds: Extract<Query<Entity, With<Cloud>>>) {
    for cloud in clouds.value().iter() {
        commands.get_or_spawn(cloud).insert(Cloud);
    }
}

The diff is:

--- a/src/clouds.rs
+++ b/src/clouds.rs
@@ -1,5 +1,5 @@
-fn extract_clouds(mut commands: Commands, clouds: Query<Entity, With<Cloud>>) {
-    for cloud in clouds.iter() {
+fn extract_clouds(mut commands: Commands, mut clouds: Extract<Query<Entity, With<Cloud>>>) {
+    for cloud in clouds.value().iter() {
         commands.get_or_spawn(cloud).insert(Cloud);
     }
 }

You can now also access resources from the render world using the normal system parameters during Extract:

fn extract_assets(mut render_assets: ResMut<MyAssets>, source_assets: Extract<Res<MyAssets>>) {
     *render_assets = source_assets.clone();
}

Please note that all existing extract systems need to be updated to match this new style; even if they currently compile they will not run as expected. A warning will be emitted on a best-effort basis if this is not met.

crates/bevy_ecs/src/event.rs

Setup infrastructure for render app owns extract Commit 'progress' Finish API Cleverly avoid needing the param to be 'static This same trick can't work for `StaticSystemParam` fwiw This is because `StaticSystemParam`'s item needs to exactly reference the original param, whereas this just stores it Migrate to the new pattern Remove `spawn_and_forget` It's unused, and was only ever needed for the weird extract logic Fix clippy errors Remove the trick because it's actually stupid Add some docs Fixup docs

james7132

Generally looks good, just one thing regarding ergonomics.

crates/bevy_render/src/extract_param.rs

james7132 · 2022-05-06T18:38:26Z

crates/bevy_render/src/lib.rs

 #[derive(Default)]
-pub struct RenderWorld(World);
+pub struct MainWorld(World);


Probably could use the Deref derive macro we have.

superdump · 2022-05-06T20:48:48Z

Did you do any benchmarks to compare?

DJMcNab · 2022-05-06T21:16:49Z

As far as I remember, I was told to do this in discord, based on a visualisation? someone had created so I did it.

I haven't benchmarked this.

Required for #4402. # Objective - derived `SystemParam` implementations were never `ReadOnlySystemParamFetch` - We want them to be, e.g. for `EventReader` ## Solution - If possible, 'forward' the impl of `ReadOnlySystemParamFetch`.

Required for bevyengine#4402. # Objective - derived `SystemParam` implementations were never `ReadOnlySystemParamFetch` - We want them to be, e.g. for `EventReader` ## Solution - If possible, 'forward' the impl of `ReadOnlySystemParamFetch`.

james7132 · 2022-06-01T19:28:32Z

@DJMcNab can you rebase this PR? I'd like to test the perf of it, but the merge conflicts are non-trivial.

DJMcNab · 2022-06-01T19:31:37Z

I'm not very keen to - I don't know that it's likely to land too, and rebasing is annoying because there's no easy way to find all of the extract systems.

At least for the latter, we can warn if an extract system doesn't read MainWorld, which should make it significantly easier.

Cleverly avoid needing the param to be 'static This same trick can't work for `StaticSystemParam` fwiw This is because `StaticSystemParam`'s item needs to exactly reference the original param, whereas this just stores it

It's unused, and was only ever needed for the weird extract logic Remove the trick because it's actually stupid

cart · 2022-07-08T23:56:17Z

bors r+

# Objective - Currently, the `Extract` `RenderStage` is executed on the main world, with the render world available as a resource. - However, when needing access to resources in the render world (e.g. to mutate them), the only way to do so was to get exclusive access to the whole `RenderWorld` resource. - This meant that effectively only one extract which wrote to resources could run at a time. - We didn't previously make `Extract`ing writing to the world a non-happy path, even though we want to discourage that. ## Solution - Move the extract stage to run on the render world. - Add the main world as a `MainWorld` resource. - Add an `Extract` `SystemParam` as a convenience to access a (read only) `SystemParam` in the main world during `Extract`. ## Future work It should be possible to avoid needing to use `get_or_spawn` for the render commands, since now the `Commands`' `Entities` matches up with the world being executed on. We need to determine how this interacts with #3519 It's theoretically possible to remove the need for the `value` method on `Extract`. However, that requires slightly changing the `SystemParam` interface, which would make it more complicated. That would probably mess up the `SystemState` api too. ## Todo I still need to add doc comments to `Extract`. --- ## Changelog ### Changed - The `Extract` `RenderStage` now runs on the render world (instead of the main world as before). You must use the `Extract` `SystemParam` to access the main world during the extract phase. Resources on the render world can now be accessed using `ResMut` during extract. ### Removed - `Commands::spawn_and_forget`. Use `Commands::get_or_spawn(e).insert_bundle(bundle)` instead ## Migration Guide The `Extract` `RenderStage` now runs on the render world (instead of the main world as before). You must use the `Extract` `SystemParam` to access the main world during the extract phase. `Extract` takes a single type parameter, which is any system parameter (such as `Res`, `Query` etc.). It will extract this from the main world, and returns the result of this extraction when `value` is called on it. For example, if previously your extract system looked like: ```rust fn extract_clouds(mut commands: Commands, clouds: Query<Entity, With<Cloud>>) { for cloud in clouds.iter() { commands.get_or_spawn(cloud).insert(Cloud); } } ``` the new version would be: ```rust fn extract_clouds(mut commands: Commands, mut clouds: Extract<Query<Entity, With<Cloud>>>) { for cloud in clouds.value().iter() { commands.get_or_spawn(cloud).insert(Cloud); } } ``` The diff is: ```diff --- a/src/clouds.rs +++ b/src/clouds.rs @@ -1,5 +1,5 @@ -fn extract_clouds(mut commands: Commands, clouds: Query<Entity, With<Cloud>>) { - for cloud in clouds.iter() { +fn extract_clouds(mut commands: Commands, mut clouds: Extract<Query<Entity, With<Cloud>>>) { + for cloud in clouds.value().iter() { commands.get_or_spawn(cloud).insert(Cloud); } } ``` You can now also access resources from the render world using the normal system parameters during `Extract`: ```rust fn extract_assets(mut render_assets: ResMut<MyAssets>, source_assets: Extract<Res<MyAssets>>) { *render_assets = source_assets.clone(); } ``` Please note that all existing extract systems need to be updated to match this new style; even if they currently compile they will not run as expected. A warning will be emitted on a best-effort basis if this is not met. Co-authored-by: Carter Anderson <mcanders1@gmail.com>

bors · 2022-07-09T00:11:36Z

Pull request successfully merged into main.

Build succeeded:

Following bevyengine#4402, it is now impossible to mutate the main world from the render world, so we split the update to the projection into a different system ran in the main world.

# Objective - Extracting resources currently always uses commands, which requires *at least* one additional move of the extracted value, as well as dynamic dispatch. - Addresses #4402 (comment) ## Solution - Write the resource into a `ResMut<R>` directly. - Fall-back to commands if the resource hasn't been added yet.

Following bevyengine#4402, it is now impossible to mutate the main world from the render world, so we split the update to the projection into a different system ran in the main world.

# Objective - Currently, the `Extract` `RenderStage` is executed on the main world, with the render world available as a resource. - However, when needing access to resources in the render world (e.g. to mutate them), the only way to do so was to get exclusive access to the whole `RenderWorld` resource. - This meant that effectively only one extract which wrote to resources could run at a time. - We didn't previously make `Extract`ing writing to the world a non-happy path, even though we want to discourage that. ## Solution - Move the extract stage to run on the render world. - Add the main world as a `MainWorld` resource. - Add an `Extract` `SystemParam` as a convenience to access a (read only) `SystemParam` in the main world during `Extract`. ## Future work It should be possible to avoid needing to use `get_or_spawn` for the render commands, since now the `Commands`' `Entities` matches up with the world being executed on. We need to determine how this interacts with bevyengine#3519 It's theoretically possible to remove the need for the `value` method on `Extract`. However, that requires slightly changing the `SystemParam` interface, which would make it more complicated. That would probably mess up the `SystemState` api too. ## Todo I still need to add doc comments to `Extract`. --- ## Changelog ### Changed - The `Extract` `RenderStage` now runs on the render world (instead of the main world as before). You must use the `Extract` `SystemParam` to access the main world during the extract phase. Resources on the render world can now be accessed using `ResMut` during extract. ### Removed - `Commands::spawn_and_forget`. Use `Commands::get_or_spawn(e).insert_bundle(bundle)` instead ## Migration Guide The `Extract` `RenderStage` now runs on the render world (instead of the main world as before). You must use the `Extract` `SystemParam` to access the main world during the extract phase. `Extract` takes a single type parameter, which is any system parameter (such as `Res`, `Query` etc.). It will extract this from the main world, and returns the result of this extraction when `value` is called on it. For example, if previously your extract system looked like: ```rust fn extract_clouds(mut commands: Commands, clouds: Query<Entity, With<Cloud>>) { for cloud in clouds.iter() { commands.get_or_spawn(cloud).insert(Cloud); } } ``` the new version would be: ```rust fn extract_clouds(mut commands: Commands, mut clouds: Extract<Query<Entity, With<Cloud>>>) { for cloud in clouds.value().iter() { commands.get_or_spawn(cloud).insert(Cloud); } } ``` The diff is: ```diff --- a/src/clouds.rs +++ b/src/clouds.rs @@ -1,5 +1,5 @@ -fn extract_clouds(mut commands: Commands, clouds: Query<Entity, With<Cloud>>) { - for cloud in clouds.iter() { +fn extract_clouds(mut commands: Commands, mut clouds: Extract<Query<Entity, With<Cloud>>>) { + for cloud in clouds.value().iter() { commands.get_or_spawn(cloud).insert(Cloud); } } ``` You can now also access resources from the render world using the normal system parameters during `Extract`: ```rust fn extract_assets(mut render_assets: ResMut<MyAssets>, source_assets: Extract<Res<MyAssets>>) { *render_assets = source_assets.clone(); } ``` Please note that all existing extract systems need to be updated to match this new style; even if they currently compile they will not run as expected. A warning will be emitted on a best-effort basis if this is not met. Co-authored-by: Carter Anderson <mcanders1@gmail.com>

# Objective - Extracting resources currently always uses commands, which requires *at least* one additional move of the extracted value, as well as dynamic dispatch. - Addresses bevyengine#4402 (comment) ## Solution - Write the resource into a `ResMut<R>` directly. - Fall-back to commands if the resource hasn't been added yet.

# Objective - Currently, the `Extract` `RenderStage` is executed on the main world, with the render world available as a resource. - However, when needing access to resources in the render world (e.g. to mutate them), the only way to do so was to get exclusive access to the whole `RenderWorld` resource. - This meant that effectively only one extract which wrote to resources could run at a time. - We didn't previously make `Extract`ing writing to the world a non-happy path, even though we want to discourage that. ## Solution - Move the extract stage to run on the render world. - Add the main world as a `MainWorld` resource. - Add an `Extract` `SystemParam` as a convenience to access a (read only) `SystemParam` in the main world during `Extract`. ## Future work It should be possible to avoid needing to use `get_or_spawn` for the render commands, since now the `Commands`' `Entities` matches up with the world being executed on. We need to determine how this interacts with bevyengine#3519 It's theoretically possible to remove the need for the `value` method on `Extract`. However, that requires slightly changing the `SystemParam` interface, which would make it more complicated. That would probably mess up the `SystemState` api too. ## Todo I still need to add doc comments to `Extract`. --- ## Changelog ### Changed - The `Extract` `RenderStage` now runs on the render world (instead of the main world as before). You must use the `Extract` `SystemParam` to access the main world during the extract phase. Resources on the render world can now be accessed using `ResMut` during extract. ### Removed - `Commands::spawn_and_forget`. Use `Commands::get_or_spawn(e).insert_bundle(bundle)` instead ## Migration Guide The `Extract` `RenderStage` now runs on the render world (instead of the main world as before). You must use the `Extract` `SystemParam` to access the main world during the extract phase. `Extract` takes a single type parameter, which is any system parameter (such as `Res`, `Query` etc.). It will extract this from the main world, and returns the result of this extraction when `value` is called on it. For example, if previously your extract system looked like: ```rust fn extract_clouds(mut commands: Commands, clouds: Query<Entity, With<Cloud>>) { for cloud in clouds.iter() { commands.get_or_spawn(cloud).insert(Cloud); } } ``` the new version would be: ```rust fn extract_clouds(mut commands: Commands, mut clouds: Extract<Query<Entity, With<Cloud>>>) { for cloud in clouds.value().iter() { commands.get_or_spawn(cloud).insert(Cloud); } } ``` The diff is: ```diff --- a/src/clouds.rs +++ b/src/clouds.rs @@ -1,5 +1,5 @@ -fn extract_clouds(mut commands: Commands, clouds: Query<Entity, With<Cloud>>) { - for cloud in clouds.iter() { +fn extract_clouds(mut commands: Commands, mut clouds: Extract<Query<Entity, With<Cloud>>>) { + for cloud in clouds.value().iter() { commands.get_or_spawn(cloud).insert(Cloud); } } ``` You can now also access resources from the render world using the normal system parameters during `Extract`: ```rust fn extract_assets(mut render_assets: ResMut<MyAssets>, source_assets: Extract<Res<MyAssets>>) { *render_assets = source_assets.clone(); } ``` Please note that all existing extract systems need to be updated to match this new style; even if they currently compile they will not run as expected. A warning will be emitted on a best-effort basis if this is not met. Co-authored-by: Carter Anderson <mcanders1@gmail.com>

# Objective - Extracting resources currently always uses commands, which requires *at least* one additional move of the extracted value, as well as dynamic dispatch. - Addresses bevyengine#4402 (comment) ## Solution - Write the resource into a `ResMut<R>` directly. - Fall-back to commands if the resource hasn't been added yet.

# Objective Following #4402, extract systems run on the render world instead of the main world, and allow retained state operations on it's resources. We're currently extracting to `ExtractedJoints` and then copying it twice during Prepare. Once into `SkinnedMeshJoints` and again into the actual GPU buffer. This makes #4902 obsolete. ## Solution Cut out the middle copy and directly extract joints into `SkinnedMeshJoints` and remove `ExtractedJoints` entirely. This also removes the per-frame allocation that is being made to send `ExtractedJoints` into the render world. ## Performance On my local machine, this halves the time for `prepare_skinned _meshes` on `many_foxes` (195.75us -> 93.93us on average). ![image](https://user-images.githubusercontent.com/3137680/205427455-ab91a8a3-a6b0-4f0a-bd48-e54482c563b2.png) --- ## Changelog Added: `BufferVec::truncate` Added: `BufferVec::extend` Changed: `SkinnedMeshJoints::build` now takes a `&mut BufferVec` instead of a `&mut Vec` as a parameter. Removed: `ExtractedJoints`. ## Migration Guide `ExtractedJoints` has been removed. Read the bound bones from `SkinnedMeshJoints` instead.

# Objective Following bevyengine#4402, extract systems run on the render world instead of the main world, and allow retained state operations on it's resources. We're currently extracting to `ExtractedJoints` and then copying it twice during Prepare. Once into `SkinnedMeshJoints` and again into the actual GPU buffer. This makes bevyengine#4902 obsolete. ## Solution Cut out the middle copy and directly extract joints into `SkinnedMeshJoints` and remove `ExtractedJoints` entirely. This also removes the per-frame allocation that is being made to send `ExtractedJoints` into the render world. ## Performance On my local machine, this halves the time for `prepare_skinned _meshes` on `many_foxes` (195.75us -> 93.93us on average). ![image](https://user-images.githubusercontent.com/3137680/205427455-ab91a8a3-a6b0-4f0a-bd48-e54482c563b2.png) --- ## Changelog Added: `BufferVec::truncate` Added: `BufferVec::extend` Changed: `SkinnedMeshJoints::build` now takes a `&mut BufferVec` instead of a `&mut Vec` as a parameter. Removed: `ExtractedJoints`. ## Migration Guide `ExtractedJoints` has been removed. Read the bound bones from `SkinnedMeshJoints` instead.

# Objective - Currently, the `Extract` `RenderStage` is executed on the main world, with the render world available as a resource. - However, when needing access to resources in the render world (e.g. to mutate them), the only way to do so was to get exclusive access to the whole `RenderWorld` resource. - This meant that effectively only one extract which wrote to resources could run at a time. - We didn't previously make `Extract`ing writing to the world a non-happy path, even though we want to discourage that. ## Solution - Move the extract stage to run on the render world. - Add the main world as a `MainWorld` resource. - Add an `Extract` `SystemParam` as a convenience to access a (read only) `SystemParam` in the main world during `Extract`. ## Future work It should be possible to avoid needing to use `get_or_spawn` for the render commands, since now the `Commands`' `Entities` matches up with the world being executed on. We need to determine how this interacts with bevyengine#3519 It's theoretically possible to remove the need for the `value` method on `Extract`. However, that requires slightly changing the `SystemParam` interface, which would make it more complicated. That would probably mess up the `SystemState` api too. ## Todo I still need to add doc comments to `Extract`. --- ## Changelog ### Changed - The `Extract` `RenderStage` now runs on the render world (instead of the main world as before). You must use the `Extract` `SystemParam` to access the main world during the extract phase. Resources on the render world can now be accessed using `ResMut` during extract. ### Removed - `Commands::spawn_and_forget`. Use `Commands::get_or_spawn(e).insert_bundle(bundle)` instead ## Migration Guide The `Extract` `RenderStage` now runs on the render world (instead of the main world as before). You must use the `Extract` `SystemParam` to access the main world during the extract phase. `Extract` takes a single type parameter, which is any system parameter (such as `Res`, `Query` etc.). It will extract this from the main world, and returns the result of this extraction when `value` is called on it. For example, if previously your extract system looked like: ```rust fn extract_clouds(mut commands: Commands, clouds: Query<Entity, With<Cloud>>) { for cloud in clouds.iter() { commands.get_or_spawn(cloud).insert(Cloud); } } ``` the new version would be: ```rust fn extract_clouds(mut commands: Commands, mut clouds: Extract<Query<Entity, With<Cloud>>>) { for cloud in clouds.value().iter() { commands.get_or_spawn(cloud).insert(Cloud); } } ``` The diff is: ```diff --- a/src/clouds.rs +++ b/src/clouds.rs @@ -1,5 +1,5 @@ -fn extract_clouds(mut commands: Commands, clouds: Query<Entity, With<Cloud>>) { - for cloud in clouds.iter() { +fn extract_clouds(mut commands: Commands, mut clouds: Extract<Query<Entity, With<Cloud>>>) { + for cloud in clouds.value().iter() { commands.get_or_spawn(cloud).insert(Cloud); } } ``` You can now also access resources from the render world using the normal system parameters during `Extract`: ```rust fn extract_assets(mut render_assets: ResMut<MyAssets>, source_assets: Extract<Res<MyAssets>>) { *render_assets = source_assets.clone(); } ``` Please note that all existing extract systems need to be updated to match this new style; even if they currently compile they will not run as expected. A warning will be emitted on a best-effort basis if this is not met. Co-authored-by: Carter Anderson <mcanders1@gmail.com>

# Objective - Extracting resources currently always uses commands, which requires *at least* one additional move of the extracted value, as well as dynamic dispatch. - Addresses bevyengine#4402 (comment) ## Solution - Write the resource into a `ResMut<R>` directly. - Fall-back to commands if the resource hasn't been added yet.

# Objective Following bevyengine#4402, extract systems run on the render world instead of the main world, and allow retained state operations on it's resources. We're currently extracting to `ExtractedJoints` and then copying it twice during Prepare. Once into `SkinnedMeshJoints` and again into the actual GPU buffer. This makes bevyengine#4902 obsolete. ## Solution Cut out the middle copy and directly extract joints into `SkinnedMeshJoints` and remove `ExtractedJoints` entirely. This also removes the per-frame allocation that is being made to send `ExtractedJoints` into the render world. ## Performance On my local machine, this halves the time for `prepare_skinned _meshes` on `many_foxes` (195.75us -> 93.93us on average). ![image](https://user-images.githubusercontent.com/3137680/205427455-ab91a8a3-a6b0-4f0a-bd48-e54482c563b2.png) --- ## Changelog Added: `BufferVec::truncate` Added: `BufferVec::extend` Changed: `SkinnedMeshJoints::build` now takes a `&mut BufferVec` instead of a `&mut Vec` as a parameter. Removed: `ExtractedJoints`. ## Migration Guide `ExtractedJoints` has been removed. Read the bound bones from `SkinnedMeshJoints` instead.

Required for bevyengine#4402. # Objective - derived `SystemParam` implementations were never `ReadOnlySystemParamFetch` - We want them to be, e.g. for `EventReader` ## Solution - If possible, 'forward' the impl of `ReadOnlySystemParamFetch`.

github-actions bot added the S-Needs-Triage This issue needs to be labelled label Apr 3, 2022

alice-i-cecile added A-Rendering Drawing game state to the screen C-Performance A change motivated by improving speed, memory usage or compile times and removed S-Needs-Triage This issue needs to be labelled labels Apr 3, 2022

alice-i-cecile mentioned this pull request Apr 3, 2022

Tracking issue: eliminate or explicitly silence all Bevy-internal execution order ambiguities #4377

Closed

11 tasks

alice-i-cecile reviewed Apr 3, 2022

View reviewed changes

crates/bevy_ecs/src/event.rs Outdated Show resolved Hide resolved

alice-i-cecile added the X-Controversial There is active debate or serious implications around merging this PR label Apr 22, 2022

DJMcNab mentioned this pull request May 3, 2022

[Merged by Bors] - Make derived SystemParam readonly if possible #4650

Closed

james7132 approved these changes May 6, 2022

View reviewed changes

DJMcNab force-pushed the render_owns_extract branch from 9ddd64d to 5e350b7 Compare May 7, 2022 10:36

alice-i-cecile added the S-Needs-Benchmarking This set of changes needs performance benchmarking to double-check that they help label May 18, 2022

alice-i-cecile added the S-Adopt-Me The original PR author has no intent to complete this work. Pick me up! label Jun 1, 2022

DJMcNab added 4 commits June 24, 2022 16:20

Setup infrastructure for render app owns extract

fbb794d

Finish API

36e9b12

Cleverly avoid needing the param to be 'static This same trick can't work for `StaticSystemParam` fwiw This is because `StaticSystemParam`'s item needs to exactly reference the original param, whereas this just stores it

Remove spawn_and_forget

80babbf

It's unused, and was only ever needed for the weird extract logic Remove the trick because it's actually stupid

Add some docs

90659d4

DJMcNab force-pushed the render_owns_extract branch from 533125a to 90659d4 Compare June 24, 2022 15:24

Merge remote-tracking branch 'origin/main' into pr/DJMcNab/4402-1

c40e3c1

bors bot changed the title ~~Make RenderStage::Extract run on the render world~~ [Merged by Bors] - Make RenderStage::Extract run on the render world Jul 9, 2022

bors bot closed this Jul 9, 2022

IceSentry added the M-Needs-Migration-Guide A breaking change to Bevy's public API that needs to be noted in a migration guide label Jul 9, 2022

DJMcNab deleted the render_owns_extract branch July 9, 2022 06:58

DJMcNab mentioned this pull request Jul 10, 2022

[Merged by Bors] - Extract resources into their target location #5271

Closed

rparrett mentioned this pull request Jul 12, 2022

Update for new bevy breaking changes Nilirad/bevy_prototype_lyon#165

Merged

zimond mentioned this pull request Jul 12, 2022

Update to work with bevy main (and eventually 0.8) mvlabat/bevy_egui#111

Merged

maniwani mentioned this pull request Oct 6, 2022

Pipelined Rendering: Deferred Extraction Commands #5082

Closed

james7132 mentioned this pull request Dec 3, 2022

[Merged by Bors] - Directly extract joints into SkinnedMeshJoints #6833

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[Merged by Bors] - Make `RenderStage::Extract` run on the render world #4402

[Merged by Bors] - Make `RenderStage::Extract` run on the render world #4402

DJMcNab commented Apr 3, 2022 •

edited

Loading

james7132 left a comment

james7132 May 6, 2022

superdump commented May 6, 2022

DJMcNab commented May 6, 2022 •

edited

Loading

james7132 commented Jun 1, 2022

DJMcNab commented Jun 1, 2022 •

edited

Loading

cart commented Jul 8, 2022

bors bot commented Jul 9, 2022

[Merged by Bors] - Make RenderStage::Extract run on the render world #4402

[Merged by Bors] - Make RenderStage::Extract run on the render world #4402

Conversation

DJMcNab commented Apr 3, 2022 • edited Loading

Objective

Solution

Future work

Todo

Changelog

Changed

Removed

Migration Guide

james7132 left a comment

Choose a reason for hiding this comment

james7132 May 6, 2022

Choose a reason for hiding this comment

superdump commented May 6, 2022

DJMcNab commented May 6, 2022 • edited Loading

james7132 commented Jun 1, 2022

DJMcNab commented Jun 1, 2022 • edited Loading

cart commented Jul 8, 2022

bors bot commented Jul 9, 2022

[Merged by Bors] - Make `RenderStage::Extract` run on the render world #4402

[Merged by Bors] - Make `RenderStage::Extract` run on the render world #4402

DJMcNab commented Apr 3, 2022 •

edited

Loading

DJMcNab commented May 6, 2022 •

edited

Loading

DJMcNab commented Jun 1, 2022 •

edited

Loading