Skip to content
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

Refactor mesh bind groups to be based on a set of flags. #10235

Closed
wants to merge 1 commit into from

Conversation

pcwalton
Copy link
Contributor

Objective

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 #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.

  • 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.

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.
@nicopap
Copy link
Contributor

nicopap commented Oct 23, 2023

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.

@nicopap
Copy link
Contributor

nicopap commented Oct 23, 2023

Do you think I should extract this particular change from #9902?

@pcwalton
Copy link
Contributor Author

@nicopap It'd probably simplify things, yeah. Feel free to land yours first, I'm happy to close this and base #10231 on your work.

@pcwalton
Copy link
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.

@nicopap
Copy link
Contributor

nicopap commented Oct 23, 2023

I can swap to a macro as you suggested in another PR. I think it would solve the issue.

@pcwalton
Copy link
Contributor Author

OK, that's fine, any way you want to automate it is good with me :)

@pcwalton
Copy link
Contributor Author

This is no longer a dependency of #10231.

@alice-i-cecile 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 C-Usability A targeted quality-of-life change that makes Bevy easier to use labels Oct 23, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Rendering Drawing game state to the screen C-Performance A change motivated by improving speed, memory usage or compile times C-Usability A targeted quality-of-life change that makes Bevy easier to use
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants