So on the steam I didn’t give a good answer, so here it is a little bit more coherently:
The occlusion systems that are traditionally used are still a benefit here - primarily GPU occlusion queries of the bounding boxes. This gives us a conservative list of the static meshes that are actually visible. This was primarily what we relied on for the demo. This approach obviously leads to false positives, so to improve this we could expose proxy meshes to better approximate the mesh bounds. And ideally we’d auto-generate these meshes to not increase the artist workload.
Alternatively it might be worth looking at building a BSP/KDTree just on the vehicle model itself since it is nearly as complex as a level itself (however since we’ll mostly be viewing it from the fringes different optimization/pessimism would be warranted).
The last approach that comes to mind is to let the GPU generate the draw lists it self and just have the CPU issue the occlusion queries and a single MultiDrawIndirect() (i.e. Vulkan/D3D12). This would eliminate the usual burden of the latency associated with occlusion queries and allow the GPU CP to drop the meshes that fail the occlusion tests.
So all that being said, we don’t have any active plans to implement these. As the Vulkan/D3D12 rhi implementation becomes more baked, we’ll likely be looking at the last option more.