TileBoundingRegion.distanceToCamera is inaccurate when camera is on opposite side of the globe

TileBoundingRegion.distanceToCamera is inaccurate when the camera is on the opposite side of the globe.

In this sandcastle rectangle A and B are on the opposite side of the globe. Rectangle A is clearly closer to the camera but the distance results say otherwise:

Distance to A: 18218478.748910885
Distance to B: 14805027.338562964

After stepping through TileBoundingRegion.distanceToCamera, the problem is that the distance from each plane (west, south, east, north) is computed using the dot product of the plane normal and a vector from one of the corners to the camera. In this specific view the distance from the east plane is much greater for rectangle A than rectangle B because the plane normal and the camera vector are more closely aligned, a situation that can only happen when the camera is on the opposite side of the globe.

This bug impacts screen space error calculations for 3D Tiles. It doesn’t impact terrain because terrain uses Horizon Culling, which is being added to 3D Tiles Next as well (see the tile metadata semantic TILE_HORIZON_OCCLUSION_POINT)

I don’t have any great suggestions for fixing this right now. One idea is to use an OBB distance check based on certain heuristics. But most likely the math can just be fixed.

[kring]

That’s a good question, and I don’t know the answer. Generally, small (high detail) quadtree tiles in a geographic projection are going to be tightly bounded by an OBB (assuming it’s computed well), but larger (low detail) ones will be pretty poor because of Earth curvature and because tiles with a fixed width in longitude degrees are narrower at their side closest to the poles. So I suspect the biggest benefit from using distance-to-region will be at sort of medium zoom levels.

I just did some really quick and dirty inspection of this, and yeah, the above looks to be correct. The distance-to-region check is only being used in tiles at levels 1-4. It makes a pretty big difference in those tiles, though, estimating the distance to be 30%-ish greater in some cases. We should probably do some deeper analysis before removing the distance-to-region computation entirely, though, or even before restricting it to coarse tiles.

[pjcozzi]

@lilleyse is it correct that a worse case improvement is to runtime convert region to the (conservative) approximate OBB and then use the OBB for culling? If so, maybe we should put that in a branch now for folks to move forward with while we work on the complete fix?

@ebogo1 I would suggest getting to go a good stopping point with KTX2 and then taking a look at this.