Refactor mesh bind groups to be based on a set of flags.#10235
Closed
pcwalton wants to merge 1 commit intobevyengine:mainfrom
Closed
Refactor mesh bind groups to be based on a set of flags.#10235pcwalton wants to merge 1 commit intobevyengine:mainfrom
pcwalton wants to merge 1 commit intobevyengine:mainfrom
Conversation
Currently, Bevy hardcodes the bind group layouts and bind groups for every combination of mesh features: `model_only`, `skinned`, `morphed`, and `morphed_skinned`. This causes a combinatorial explosion when new mesh features are added, as PR bevyengine#10231 does for lightmaps. To solve this, PR introduces `MeshLayoutKey`, which is a set of flags that define which mesh features are enabled. All possible combinations of bind group layouts and bind groups are generated generically, so new mesh features can be easily added in the future. To avoid a runtime combinatorial explosion, the following optimizations have been added: * Some flags are marked *generic*, which means that bind groups with them only have to be generated once and then can be reused across all meshes. * `SKINNED` and `MORPHED` bind groups are never generated if the scene doesn't contain any skinned or morphed meshes, respectively. * `SKINNED` and `MORPHED` bind groups are only generated for meshes that actually have skins or morph targets, respectively.
Merged
Contributor
|
I don't think this should be merged. I already refactor this bit of code in #9902 using a similar pattern, though with less code still. |
Contributor
|
Do you think I should extract this particular change from #9902? |
Contributor
Author
Contributor
Author
|
@nicopap Actually, wait, I see you're writing out every combination of morphed, skinned, and motion vectors in VariantsData. This will increase from 8 variants to 16 with lightmaps, which is a lot. This PR would avoid that. |
Contributor
|
I can swap to a macro as you suggested in another PR. I think it would solve the issue. |
Contributor
Author
|
OK, that's fine, any way you want to automate it is good with me :) |
Contributor
Author
|
This is no longer a dependency of #10231. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
Objective
Currently, Bevy hardcodes the bind group layouts and bind groups for every combination of mesh features:
model_only,skinned,morphed, andmorphed_skinned. This causes a combinatorial explosion when new mesh features are added, as PR #10231 does for lightmaps.Solution
To solve this, PR introduces
MeshLayoutKey, which is a set of flags that define which mesh features are enabled. All possible combinations of bind group layouts and bind groups are generated generically, so new mesh features can be easily added in the future.To avoid a runtime combinatorial explosion, the following optimizations have been added:
Some flags are marked generic, which means that bind groups with them only have to be generated once and then can be reused across all meshes.
SKINNEDandMORPHEDbind groups are never generated if the scene doesn't contain any skinned or morphed meshes, respectively.SKINNEDandMORPHEDbind groups are only generated for meshes that actually have skins or morph targets, respectively.