Terrain tiles not culled during offscreen pick pass

[dennisadams]

Not much of a bug, but possibly a potenial improvement. Picking.js' getRayIntersection renders the scene from an offscreen camera, typically for clamping or height sampling.
In this process, the 3D tilesets are updated once and non-visible tiles are culled. However, terrain-tile commands are copied as is, although many aren't visible from the offscreen camera. Especially in case of clamping or height sampling, where typically only 1 tile is expected to intersect the orthographic top-down frustum.

The straightforward benefit of culling these tiles, though not major, is saving some rendering work.

Another benefit is that this will allow tighter frustum near/far bounds when executing the commands, and thus better precision. For standard users the precision should be good enough regardless, but while testing a cheap Android device, I had precision issues in the Clamp to 3D Tiles and Sample Height from 3D Tiles sandcastles. What triggered the precision problems is that low-level terrain tiles were spanning over large depth ranges and forcing a maximally-spaced multifrustum. The fact that the offscreen camera is far away from the scene (9000.0m high, the defaultMaxTerrainHeight) also didn't help.

If someone would like to look into it, GlobeSurfaceTileProvider.updateForPick is where the commands are copied. Perhaps a solution would be to check there the tile visibility if passes.pick && passes.offscreen.

If visibility is checked using the bounding volume (like GlobeSurfaceTileProvider.computeTileVisibility does) it will help, but it's still likely that some low-level tiles will be rendered because of big bounding volumes. In the clamping/sampling case we can do better by checking if the camera's cartographic is contained in the tile's rectangle and that should eliminate all rogue tiles and allow tight frustum bounds. But this might be too cumbersome.

[dennisadams]

Another benefit is that this will allow tighter frustum near/far bounds when executing the commands, and thus better precision. For standard users the precision should be good enough regardless, but while testing a cheap Android device, I had precision issues in the Clamp to 3D Tiles and Sample Height from 3D Tiles sandcastles.

With #9064 merged, precision is not an issue anymore, even on my device.