Tileset being selected for rendering on the other side of the globe?

[mramato]

1. Start this Sandcastle Which loads the Montreal tileset. It also has a postRender event registered which prints out the number of montreal tiles selected for rendering whenever the selected value changes.

2. Type Jamaica into the geocoder and fly there. (Still 0 tiles selected for rendering)

3. Tilt the camera towards the horizon, you'll notice that the root tile of Montreal gets selected, even though it is well below the horizon practically on the other side of the earth. Zooming in close to the ground doesn't fix this either, the moment you are looking at the horizon, it selects the tile.

This seems to happens whether terrain or depthTestAgainstTerrain is on or off, so I don't think that's the problem. @likangning93 thinks maybe something is wrong with horizon culling?

[mramato]

@lilleyse or @loshjawrence any ideas what might be causing this?

[loshjawrence]

Even if horizon culling is the culprit, I'm surprised that sse is satisfied for the root tile that far away.

[lilleyse]

3D Tiles doesn't do ellipsoid horizon/occlusion culling currently, just frustum culling. We should copy what terrain/imagery does.

[mramato]

@lilleyse any change we can get to this before the next release?

[likangning93]

Even if horizon culling is the culprit, I'm surprised that sse is satisfied for the root tile that far away.

I live in Montreal and went on vacation in Jamaica, why can I see my house from here?!

[lilleyse]

Workaround in Sandcastle in case anyone needs to reference it in the future. Not as good as computing per tile horizon occlusion points though:

Sandcastle

[mramato]

Just retested this, hoping it would b fixed. I had to go to Florida instead of Jamaica, but it still ends up selecting the tile even when it's nowhere near the camera view

[kring]

In cesium-native, we don't do horizon culling at all, because using the ellipsoid is an occluder is unreliable when terrain and photogrammetry may be below it. However, a tile like this on the other side of the globe will get culled by fog. Could be worth doing something similar in CesiumJS if we're not already.

[mramato]

Funny you say that, since fog has the opposite problem in CesiumJS: #8454

@lilleyse Have these two issues been around for so long because they are hard to fix? Or have they just not been a priority? Seems like a solid improvement when it comes to performance and tile selection.

CC @ggetz @sanjeetsuhag

[kring]

There's a good chance cesium-native has that fog culling artifact as well, since the implementation is the same. I've never noticed it, though.