-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Merged by Bors] - use better set inheritance in render systems #7524
[Merged by Bors] - use better set inheritance in render systems #7524
Conversation
.configure_sets( | ||
( | ||
PrepareAssetLabel::PreAssetPrepare, | ||
PrepareAssetLabel::AssetPrepare, | ||
PrepareAssetLabel::PostAssetPrepare, | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This only needs to be configured once. But because this is in RenderAssetPlugin<A>
, it will be configured for every render asset A
. I don't think there is a better place to put it, because the RenderAssetPlugin
should work without e.g. the PbrPlugin
.
Is configure_sets
idempotent? Or should there be a if !initialized { configure(); initialized = true }
is some way?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
configure_sets should be idempotent. If it's not, that's a bug.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree with this set of changes. This is a better pattern in general: I just didn't want to make the migration PR even muddier than it needed to be.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
noticed that there's an apply_system_buffers and prepare_materials that are free floating. I'd be ok with fixing that in this pr or doing that in a separate pr.
bors r+ |
# Objective Some render systems that have system set used as a label so that they can be referenced from somewhere else. The 1:1 translation from `add_system_to_stage(Prepare, prepare_lights.label(PrepareLights))` is `add_system(prepare_lights.in_set(Prepare).in_set(PrepareLights)`, but configuring the `PrepareLights` set to be in `Prepare` would match the intention better (there are no systems in `PrepareLights` outside of `Prepare`) and it is easier for visualization tools to deal with. # Solution - replace ```rust prepare_lights in PrepareLights prepare_lights in Prepare ``` with ```rs prepare_lights in PrepareLights PrepareLights in Prepare ``` **Before** ![before](https://user-images.githubusercontent.com/22177966/216961792-a0f5eba7-f161-4994-b5a4-33e98763a3b0.svg) **After** ![after](https://user-images.githubusercontent.com/22177966/216961790-857d0062-7943-49ef-8927-e602dfbab714.svg)
Pull request successfully merged into main. Build succeeded:
|
Objective
Some render systems that have system set used as a label so that they can be referenced from somewhere else.
The 1:1 translation from
add_system_to_stage(Prepare, prepare_lights.label(PrepareLights))
isadd_system(prepare_lights.in_set(Prepare).in_set(PrepareLights)
, but configuring thePrepareLights
set to be inPrepare
would match the intention better (there are no systems inPrepareLights
outside ofPrepare
) and it is easier for visualization tools to deal with.Solution
with
Before
After