Divide the single VisibleEntities list into separate lists for 2D meshes, 3D meshes, lights, and UI elements, for performance.
#12582
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
meshes, 3D meshes, and lights, for performance. This commit splits `VisibleEntities::entities` into three separate lists: one for lights, one for 2D meshes, and one for 3D meshes. This allows `queue_material_meshes` and similar methods to avoid examining entities that are obviously irrelevant. In particular, this separation helps scenes with many skinned meshes, as the individual bones are considered visible entities but have no rendered appearance. Internally, `VisibleEntities::entities` is a `HashMap` from the `TypeId` representing a `QueryFilter` to the appropriate `Entity` list. I had to do this because `VisibleEntities` is located within an upstream crate from the crates that provide lights (`bevy_pbr`) and 2D meshes (`bevy_sprite`). As an added benefit, this setup allows apps to provide their own types of renderable components, by simply adding a specialized `check_visibility` to the schedule. Currently, this provides minimal performance benefit in `many_foxes`, but on top of binning (bevyengine#12453) it provides a 20% end-to-end speedup on that benchmark. * `check_visibility` and `VisibleEntities` now store the three types of renderable entities--2D meshes, 3D meshes, and lights--separately. If your custom rendering code examines `VisibleEntities`, it will now need to specify which type of entity it's interested in using the `WithMesh2d`, `WithMesh`, and `WithLight` types respectively. If your app introduces a new type of renderable entity, you'll need to add an explicit call to `check_visibility` to the schedule to accommodate your new component or components.
alice-i-cecile
added
A-Rendering
|
How do UI entities fit into this categorization? |
alice-i-cecile
added
the
C-Breaking-Change
|
They should be 2D meshes, but I'll check. If they aren't handled then I can just add them to the HashMap. (This is why I made it extensible.) |
|
I added UI entities to the hash map. |
pcwalton
changed the title
VisibleEntities list into separate lists for 2D meshes, 3D meshes, and lights, for performance.VisibleEntities list into separate lists for 2D meshes, 3D meshes, lights, and UI elements, for performance.
NthTensor
reviewed
Apr 1, 2024
NthTensor
approved these changes
Apr 1, 2024
|
Addressed review comments and merge conflicts. |
kristoff3r
approved these changes
Apr 11, 2024
alice-i-cecile
added
the
S-Ready-For-Final-Review
|
@pcwalton once merge conflicts are resolved I'll merge this. The doc improvements mentioned by @kristoff3r would be great too. |
|
Done. @alice-i-cecile |
auto-merge was automatically disabled
April 11, 2024 19:57
Head branch was pushed to by a user without write access
pcwalton
added a commit
to pcwalton/bevy
that referenced
this pull request
Apr 12, 2024
`Sprite`, `Text`, and `Handle<MeshletMesh>` were types of renderable entities that the new segregated visible entity system didn't handle, so they didn't appear. Because `bevy_text` depends on `bevy_sprite`, and the visibility computation of text happens in the latter crate, I had to introduce a new marker component, `SpriteSource`. `SpriteSource` marks entities that aren't themselves sprites but become sprites during rendering. I added this component to `Text2dBundle`. Unfortunately, this is technically a breaking change, although I suspect it won't break anybody in practice except perhaps editors.
github-merge-queue bot
pushed a commit
that referenced
this pull request
Apr 13, 2024
`Sprite`, `Text`, and `Handle<MeshletMesh>` were types of renderable entities that the new segregated visible entity system didn't handle, so they didn't appear. Because `bevy_text` depends on `bevy_sprite`, and the visibility computation of text happens in the latter crate, I had to introduce a new marker component, `SpriteSource`. `SpriteSource` marks entities that aren't themselves sprites but become sprites during rendering. I added this component to `Text2dBundle`. Unfortunately, this is technically a breaking change, although I suspect it won't break anybody in practice except perhaps editors. Fixes #12935. ## Changelog ### Changed * `Text2dBundle` now includes a new marker component, `SpriteSource`. Bevy uses this internally to optimize visibility calculation. ## Migration Guide * `Text` now requires a `SpriteSource` marker component in order to appear. This component has been added to `Text2dBundle`.
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.
This commit splits
VisibleEntities::entitiesinto four separate lists: one for lights, one for 2D meshes, one for 3D meshes, and one for UI elements. This allowsqueue_material_meshesand similar methods to avoid examining entities that are obviously irrelevant. In particular, this separation helps scenes with many skinned meshes, as the individual bones are considered visible entities but have no rendered appearance.Internally,
VisibleEntities::entitiesis aHashMapfrom theTypeIdrepresenting aQueryFilterto the appropriateEntitylist. I had to do this becauseVisibleEntitiesis located within an upstream crate from the crates that provide lights (bevy_pbr) and 2D meshes (bevy_sprite). As an added benefit, this setup allows apps to provide their own types of renderable components, by simply adding a specializedcheck_visibilityto the schedule.This provides a 16.23% end-to-end speedup on
many_foxeswith 10,000 foxes (24.06 ms/frame to 20.70 ms/frame).Migration guide
check_visibilityandVisibleEntitiesnow store the four types of renderable entities--2D meshes, 3D meshes, lights, and UI elements--separately. If your custom rendering code examinesVisibleEntities, it will now need to specify which type of entity it's interested in using theWithMesh2d,WithMesh,WithLight, andWithNodetypes respectively. If your app introduces a new type of renderable entity, you'll need to add an explicit call tocheck_visibilityto the schedule to accommodate your new component or components.Analysis
many_foxes, 10,000 foxes:main:many_foxes, 10,000 foxes, this branch:queue_material_meshes(yellow = this branch, red =main):queue_shadows(yellow = this branch, red =main):