Remove the type parameter from check_visibility, and only invoke it once.

[pcwalton]

Currently, check_visibility is parameterized over a query filter that specifies the type of potentially-visible object. This has the unfortunate side effect that we need a separate system, mark_view_visibility_as_changed_if_necessary, to trigger view visibility change detection. That system is quite slow because it must iterate sequentially over all entities in the scene.

This PR moves the query filter from check_visibility to a new component, VisibilityClass. VisibilityClass stores a list of type IDs, each corresponding to one of the query filters we used to use. Because check_visibility is no longer specialized to the query filter at the type level, Bevy now only needs to invoke it once, leading to better performance as check_visibility can do change detection on the fly rather than delegating it to a separate system.

This commit also has ergonomic improvements, as there's no need for applications that want to add their own custom renderable components to add specializations of the check_visibility system to the schedule. Instead, they only need to ensure that the ViewVisibility component is properly kept up to date. The recommended way to do this, and the way that's demonstrated in the custom_phase_item and specialized_mesh_pipeline examples, is to make ViewVisibility a required component and to add the type ID to it in a component add hook. This patch does this for Mesh3d, Mesh2d, Sprite, Light, and Node, which means that most app code doesn't need to change at all.

Note that, although this patch has a large impact on the performance of visibility determination, it doesn't actually improve the end-to-end frame time of many_cubes. That's because the render world was already effectively hiding the latency from
mark_view_visibility_as_changed_if_necessary. This patch is, however, necessary for further improvements to many_cubes performance.

many_cubes trace before:

many_cubes trace after:

Migration Guide

• check_visibility no longer takes a QueryFilter, and there's no need to add it manually to your app schedule anymore for custom rendering items. Instead, entities with custom renderable components should add the appropriate type IDs to VisibilityClass. See custom_phase_item for an example.

[ItsDoot]

How much more work would it be to store ComponentId instead of TypeId? The former would be more introspect-able.

[pcwalton]

@ItsDoot I just tried it, and unfortunately it's not really possible because those IDs get fed into the render world, and component IDs are per-world.

[JMS55]

@pcwalton need to do the same for MeshletMesh3d, conditionally when the MeshletPlugin is loaded.

[pcwalton]

@JMS55 Good point, added meshlet support.