You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Divide the single VisibleEntities list into separate lists for 2D meshes, 3D meshes, lights, and UI elements, for performance. (#12582)
This commit splits `VisibleEntities::entities` into four separate lists:
one for lights, one for 2D meshes, one for 3D meshes, and one for UI
elements. 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.
This provides a 16.23% end-to-end speedup on `many_foxes` with 10,000
foxes (24.06 ms/frame to 20.70 ms/frame).
## Migration guide
* `check_visibility` and `VisibleEntities` now store the four types of
renderable entities--2D meshes, 3D meshes, lights, and UI
elements--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`, `WithLight`, and
`WithNode` 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.
## 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`):

/// Controls the resolution of [`DirectionalLight`] shadow maps.
102
107
#[derive(Resource,Clone,Debug,Reflect)]
103
108
#[reflect(Resource)]
@@ -432,19 +437,19 @@ fn calculate_cascade(
432
437
texel_size: cascade_texel_size,
433
438
}
434
439
}
435
-
/// Add this component to make a [`Mesh`](bevy_render::mesh::Mesh) not cast shadows.
440
+
/// Add this component to make a [`Mesh`] not cast shadows.
436
441
#[derive(Component,Reflect,Default)]
437
442
#[reflect(Component,Default)]
438
443
pubstructNotShadowCaster;
439
-
/// Add this component to make a [`Mesh`](bevy_render::mesh::Mesh) not receive shadows.
444
+
/// Add this component to make a [`Mesh`] not receive shadows.
440
445
///
441
446
/// **Note:** If you're using diffuse transmission, setting [`NotShadowReceiver`] will
442
447
/// cause both “regular” shadows as well as diffusely transmitted shadows to be disabled,
443
448
/// even when [`TransmittedShadowReceiver`] is being used.
444
449
#[derive(Component,Reflect,Default)]
445
450
#[reflect(Component,Default)]
446
451
pubstructNotShadowReceiver;
447
-
/// Add this component to make a [`Mesh`](bevy_render::mesh::Mesh) using a PBR material with [`diffuse_transmission`](crate::pbr_material::StandardMaterial::diffuse_transmission)`> 0.0`
452
+
/// Add this component to make a [`Mesh`] using a PBR material with [`diffuse_transmission`](crate::pbr_material::StandardMaterial::diffuse_transmission)`> 0.0`
448
453
/// receive shadows on its diffuse transmission lobe. (i.e. its “backside”)
449
454
///
450
455
/// Not enabled by default, as it requires carefully setting up [`thickness`](crate::pbr_material::StandardMaterial::thickness)
0 commit comments