Concepts for supporting Occlusion Culling

If a tile can't be seen because it is behind other geometry or not rendered because it is off screen / the tile geometry doesn't match the bounding box well then it's not worth refining the tile to the next layers. If a parent tile is already refined and then suddenly wouldn't be visible because the camera moved then the parents occlusion visibility can be inferred from child tiles, similar to frustum culling (though this may cause similar issues to the frustum culling approach due to parent tile sets being implicitly removed resulting in cyclic loading. See #741) (Child tiles may also not be visible while a parent tile is due to geometry differences, also potentially resulting in cyclic loading if not handled correctly).

Occlusion culling could be done in the following ways and added as a plugin - it shouldn't need to be synchronous:

• Occlusion queries (may not work well with batched mesh, occlusion queries may just report if something was rendered at all during the rasterization process, not if it's visible by the end of the render pipeline - eg the first mesh rendered in a scene will always be considered visible)
• GPU id rasterization, readback (best done as part of a broader pipeline) (can be counted and returned via compute shader, rendered at lower resolution)
• CPU worker rasterization
• CPU raycasting to determine visibility (in worker?)

No files, tests, or entry points are named. Start by reviewing the existing frustum-culling behavior and issue #741, then compare the proposed occlusion-query, GPU rasterization, CPU worker rasterization, and raycasting approaches. Done would require a chosen approach and clear handling for parent and child visibility without cyclic loading.