Reextract a mesh on the next frame if its material couldn't be prepared on the frame we first encountered it.#17963
Merged
superdump merged 1 commit intobevyengine:mainfrom Feb 22, 2025
Conversation
on the frame we first encountered it. We might not be able to prepare a material on the first frame we encounter a mesh using it for various reasons, including that the material hasn't been loaded yet or that preparing the material is exceeding the per-frame cap on number of bytes to load. When this happens, we currently try to find the material in the `MaterialBindGroupAllocator`, fail, and then fall back to group 0, slot 0, the default `MaterialBindGroupId`, which is obviously incorrect. Worse, we then fail to dirty the mesh and reextract it when we *do* finish preparing the material, so the mesh will continue to be rendered with an incorrect material. This patch fixes both problems. In `collect_meshes_for_gpu_building`, if we fail to find a mesh's material in the `MeshBindGroupAllocator`, then we detect that case, bail out, and add it to a list, `MeshesToReextractNextFrame`. On subsequent frames, we process all the meshes in `MeshesToReextractNextFrame` as though they were changed. This ensures both that we don't render a mesh if its material hasn't been loaded and that we start rendering the mesh once its material does load. This was first noticed in the intermittent Pixel Eagle failures in the `testbed_3d` patch in bevyengine#17898, although the problem has actually existed for some time. I believe it just so happened that the changes to the allocator in that PR caused the problem to appear more commonly than it did before.
Contributor
Contributor
|
on |
superdump
approved these changes
Feb 22, 2025
atlv24
approved these changes
Feb 22, 2025
Contributor
atlv24
left a comment
There was a problem hiding this comment.
Appreciate the minor cleanup refactors and type extraction.
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
5 participants
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.
We might not be able to prepare a material on the first frame we encounter a mesh using it for various reasons, including that the material hasn't been loaded yet or that preparing the material is exceeding the per-frame cap on number of bytes to load. When this happens, we currently try to find the material in the
MaterialBindGroupAllocator, fail, and then fall back to group 0, slot 0, the defaultMaterialBindGroupId, which is obviously incorrect. Worse, we then fail to dirty the mesh and reextract it when we do finish preparing the material, so the mesh will continue to be rendered with an incorrect material.This patch fixes both problems. In
collect_meshes_for_gpu_building, if we fail to find a mesh's material in theMeshBindGroupAllocator, then we detect that case, bail out, and add it to a list,MeshesToReextractNextFrame. On subsequent frames, we process all the meshes inMeshesToReextractNextFrameas though they were changed. This ensures both that we don't render a mesh if its material hasn't been loaded and that we start rendering the mesh once its material does load.This was first noticed in the intermittent Pixel Eagle failures in the
testbed_3dpatch in #17898, although the problem has actually existed for some time. I believe it just so happened that the changes to the allocator in that PR caused the problem to appear more commonly than it did before.