[Merged by Bors] - Add RenderWorld to Extract step #2555
Closed
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
64 tasks
|
bors r+ |
bors bot
pushed a commit
that referenced
this pull request
Jul 28, 2021
Makes the "Render App World" directly available to Extract step systems as a `RenderWorld` resource. Prior to this, there was no way to directly read / write render world state during the Extract step. The only way to make changes was through Commands (which were applied at the end of the stage).
```rust
// `thing` is an "app world resource".
fn extract_thing(thing: Res<Thing>, mut render_world: ResMut<RenderWorld>) {
render_world.insert_resource(ExtractedThing::from(thing));
}
```
RenderWorld makes a number of scenarios possible:
* When an extract system does big allocations, it is now possible to reuse them across frames by retrieving old values from RenderWorld (at the cost of reduced parallelism from unique RenderWorld borrows).
* Enables inserting into the same resource across multiple extract systems
* Enables using past RenderWorld state to inform future extract state (this should generally be avoided)
Ultimately this is just a subset of the functionality we want. In the future, it would be great to have "multi-world schedules" to enable fine grained parallelism on the render world during the extract step. But that is a research project that almost certainly won't make it into 0.6. This is a good interim solution that should easily port over to multi-world schedules if/when they land.
|
Pull request successfully merged into pipelined-rendering. Build succeeded: |
bors
bot
changed the title
bors bot
pushed a commit
that referenced
this pull request
Aug 4, 2021
# Objective Restore the functionality of sprite atlases in the new renderer. ### **Note:** This PR relies on #2555 ## Solution Mostly just a copy paste of the existing sprite atlas implementation, however I unified the rendering between sprites and atlases. Co-authored-by: Carter Anderson <mcanders1@gmail.com>
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.
Makes the "Render App World" directly available to Extract step systems as a
RenderWorldresource. Prior to this, there was no way to directly read / write render world state during the Extract step. The only way to make changes was through Commands (which were applied at the end of the stage).RenderWorld makes a number of scenarios possible:
Ultimately this is just a subset of the functionality we want. In the future, it would be great to have "multi-world schedules" to enable fine grained parallelism on the render world during the extract step. But that is a research project that almost certainly won't make it into 0.6. This is a good interim solution that should easily port over to multi-world schedules if/when they land.