Tighter frustum culling for 3D Tiles without contentBoundingVolume

[lilleyse]

#9172 exposed a case where a draw command is deemed visible by 3D Tiles but is not actually visible when bucketed into frustum commands in View. The reason for the discrepancy is that 3D Tiles does its own internal traversal using tile bounding volumes from tileset.json rather than using content bounding volumes computed from the glTF content. #9172 (comment) goes into more details:

DrawCommand has a cull property to indicate whether View should do frustum culling on the command. All draw commands coming from 3D Tiles will have this set to false since 3D Tiles does its own internal frustum culling during traversal and doesn't expect View to have to do this check again. The problem is that a tile might be considered visible during traversal but its content might not actually be visible, and this is likely to occur if the bounding volume in tileset.json is significantly larger than the bounding volume computed for the content (which is computed from the glTF position accessor min/max). So the command is visible from the tileset's perspective, gets pushed to the command list, goes through View, modifies camera near/far and shadow near/far, but ultimately doesn't get placed into any frustum command lists because it's behind all the frustums. As a result it doesn't get rendered but it does move the near plane of the camera and shadows much nearer than necessary.

A possible fix would be for 3D Tiles to use the tile's bounding volume for traversal and the draw command's bounding volume for selection (as long as the tile content is loaded). Normally 3D Tiles uses contentBoundingVolume for tighter culling but it's not always present in tileset.json.