GlobeControls limit Frustum with horizon for performance

[AlaricBaraou]

Currently for simplicity GlobeControls camera far is far enough to include the entire earth resulting in unnecessary tiles being loaded.

With these changes we limit the frustum to the distance of the horizon based on our current latitude and elevation.

This seems to work well but some tiles are being loaded while they don't intersect the frustum.

I edited the googleMapsExample.js to visualize it.

I'm not sure where is the issue but I'm pretty sure it's either the frustum or the OOB.
This particular example might help identifying the issue, when the camera is zoomed in on the north pole we get false positive on the intersectsFrustum check.
If we look at it from the side, it's considered like an intersection as it seems like the frustum far limit does intersect with the obbs.

But if we look at it from above, we can see that the frustum doesn't.

Those false positive unload as soon as on the side view, the frustum move outside of those obb.

[gkjohnson]

Awesome! I'll take a deeper look at this next week. It would be nice to have some before / after stats on the number of tiles loaded and number of tiles rendered after the changes you've made so far.

I'm not sure where is the issue but I'm pretty sure it's either the frustum or the OOB.
This particular example might help identifying the issue, when the camera is zoomed in on the north pole we get false positive on the intersectsFrustum check.

I took a look and the issue is in the OBB frustum intersect code. In fact three.js' AABB frustum intersect code that the OBB logic is based on isn't correct, either. It will mark bounds as in the frustum even when they're clearly outside of it since it's only checking if the box is completely on one side of any plane which misses the common case of a box that intersects multiple planes if it's large. Here's a demo:

https://jsfiddle.net/89rtuaqp/2/

This post discusses the problem and a correct application of separating axis theorem. I'll make a three.js issue. We can see what they say - we may have to make our own extended frustum class that stores enough data for performing a more correct OBB intersection test.

[gkjohnson]

mrdoob/three.js#27756 may take a bit to resolve so I think it's best for us to modify our current implementation to be more robust, but I think that can happen in another PR. This can be done by storing the frustum corners as points on the Frustum so they can be tested against the OBB planes as referenced in the inigo post.

[AlaricBaraou]

Good timing, I was working on a custom Frustum but it's hard to test it with the tiles logic, I might try in a simpler environment.

I added a class AdvFrustum that calculate the points of the Frustum to use them for different operations as suggested in the article you linked. But I think there are still case that are not handled or it might be the logic of the nested tiles etc that I don't really grasp at the moment.

Also the latest commit take care of "Google Maps Example: Add ability to specify height in hash" #482

[AlaricBaraou]

a simpler example to play with it

https://jsfiddle.net/0sb3gden/30/

The extended Frustum works well with axis aligned box but not with OBB at the moment.

[AlaricBaraou]

I was about to write that it's good now but apparently now we have some false negative.

Looking good here outside of the fact that the tiles bounding box are bigger than necessary but that's not from this PR

But here it discard some tiles that are in obvious intersections.

I`ll try to reproduce that one in jsfiddle
edit: yes it creates a false negative on this one
https://jsfiddle.net/627tdm3e/174/
I'll investigate tomorrow.

edit edit: two of my box planes are wrong, I'll fix it

[gkjohnson]

It looks like we're getting some depth fighting issues - but it looks like this was already happening 🤔

We can look at this in another PR but we might want to find a smarter way to set the "near" value.

[gkjohnson]

Added some comments for some small things to change - and a few questions on the example and GlobeControls additions.

[AlaricBaraou]

I addressed all points, just a note about this issue #482
It can't be init under a certain height, at least in the area I was testing it.
I added a comment to check later

[gkjohnson]

It can't be init under a certain height, at least in the area I was testing it.

Likely what's happening is that the coarse levels of detail on the model load and have a much higher height than the lower LoDs which pushes the camera up due to the "GlobeControls" update function. I think it's okay to say that this fixes #482.

[gkjohnson]

A few stats - some very nice improvements!

Top Down View

	Before	After	% improvement
visible tiles	104	55	~47%
loaded tiles	307	189	~38%

Horizon View

	Before	After	% improvement
visible tiles	332	186	~43%
loaded tiles	574	376	~34%

[gkjohnson]

One thing I did notice is that the globe controls far plane will clip the horizon a bit. It's subtle but you can see it change a little. Likely due to the earth model not exactly matching the ellipsoid. We don't have to fix it immediately but may something to keep in mind for the future there are ideas on how to address it.

Before

After