What problem does this solve or what need does it fill?

The current check_visibility visibility system is overall good. It uses frustum culling in parallel but to do so it has to iterate and check all entities with visibility components. Iterating and checking every entity with visibility components, even if done in parallel, is not cheap.

Here we see:
Yellow: 9_620 sprites in camera view
Red: 9_620 sprites in camera view + 1_154_400 sprites off camera view

Don't get me wrong. Checking 1M sprites in 2.4ms (2.64ms all - 217µs in view) is impressive but it would be better if we could skip it.

Not all games could offer this but 2d grid based games are quite popular. Because their entities are on grid it's very cheap to find out what's in/off camera's view - get camera's position, translate it to grid position and bounding box, iterate through the box and check if position is in grid position to entity mapping

If all sprites are inside the camera view then it's quite expensive but if a lot of entities are outside of the view then it's cheap - the number of grid positions is constant compared to current check_visibility impl.

And now comes finally my title.

I would like to have some mechanism to set-up a custom visibility system for my entities.
This way I could pick the best way of checking visibility for my entities.
Map made of sprites arranged in grid ? Use my constant time visibility checking.
Special effects/particles ? Let bevy handle it
etc..

What solution would you like?

Maybe some marker component which disables bevy's check_visibility for it ? - Then the marker component could be added the check_visibility and other visibility queries Without<NoVisibilityChecking>

Then 1 of these:

1. Then I would have to place a system in PostUpdate, ordered after check_visibility which would query visibility entities with bevy's marker component and my own - so I don't potentially touch other NoVisibilityChecking entities. This system would then add entities to the camera/emit event add entities to camera or something.

2. Or maybe some CustomVisibility trait which I would have to implement on struct. I would have to impl method which would do the efficient checking. Then I would have to register it with bevy and bevy would handle system ordering and such for me ? It would send events, return vec with entities or something ??

trait CustomVisibility {
    type MarkerComponent: Component;
    type SystemParam: SystemParam;

   fn system(impl_specific_stuff: Self::SystemParam, visibility_query: Query<..., (With<NoVisibilityChecking>, With<Self::MarkerComponent>)>);
}

What alternative(s) have you considered?

Bevy could have a built-in way of differentiating between unbounded and on grid entities and then it would efficiently handle it. - marker componments ?

Additional context