Only load visible tiles during 3D Tiles traversal

[lilleyse]

Fixes #5477

The traversal was not checking the visibility of a tile before loading it. This primarily affected situations where at least one child was visible but many other children weren't. After running the numbers I noticed big wins on some additive-refinement tilesets like in #5477 (256 tiles vs 19), NYC (201 vs 176) and less for replacement-refinement (San Miguel: 278 vs 265).

@jbo023 can you double-check this for your tilesets?

[cesium-concierge]

@lilleyse, thanks for the pull request! Maintainers, we have a signed CLA from @lilleyse, so you can review this at any time.

I noticed that CHANGES.md has not been updated. If this change updates the public API in any way, fixes a bug, or makes any non-trivial update, please add a bullet point to CHANGES.md and comment on this pull request so we know it was updated. For more info, see the Pull Request Guidelines.

I am a bot who helps you make Cesium awesome! Thanks again.

[jbo023]

@lilleyse thanks, i will check with our datasets

[jbo023]

@lilleyse I checked with some of our datasets. Its much better then before 👍

var viewer = new Cesium.Viewer('cesiumContainer');
var scene = viewer.scene;
viewer.extend(Cesium.viewerCesium3DTilesInspectorMixin);
var camera = scene.camera;
camera.setView({
    "destination": {
        "x": 3784121.7862312756,
        "y": 899825.2027559757,
        "z": 5038031.98712454
    },
    "orientation": {
        "heading": 1.2632693125934953,
        "pitch": -0.2218534463463045,
        "roll": 0
    }
});
var tileset = scene.primitives.add(new Cesium.Cesium3DTileset({
	url : 'https://d35ei6ur3bjvr1.cloudfront.net/berlin/3c2a32d3-633c-462d-b79c-7215dcfbc44f'	
}));
scene.terrainProvider = new Cesium.CesiumTerrainProvider({
	url: 'https://d35ei6ur3bjvr1.cloudfront.net/berlin/86bd7c93-de44-455d-9efa-a41238172216'
});

But maybe we can do another optimization. If I use the above sandcastlecode the new code loads 85 b3dm tiles (without this change 255). But only 21 tiles are selected.
Maybe if we calculate the sse before loading the tile content we can save another 64 requests.

[lilleyse]

But maybe we can do another optimization. If I use the above sandcastlecode the new code loads 85 b3dm tiles (without this change 255). But only 21 tiles are selected.
Maybe if we calculate the sse before loading the tile content we can save another 64 requests.

Agreed - something more needs to be done during the base traversal code to not load so aggressively. Setting immediatelyLoadDesiredLevelOfDetail will load exactly what is needed now. I should have something better soon - and yes SSE will probably come into play.

[lilleyse]

@jbo023 Updated. # Content Ready now equals # Selected for the initial view.

I tested out a few other data sets and didn't notice any issues, but someone else should quickly check as they review.

[pjcozzi]

@austinEng any chance you have a few minutes to look at this? We would like to include this in tomorrow's release.

[pjcozzi]

@likangning93 could you also please test this on a few datasets?

[austinEng]

You may want to check this, but I believe that by the time you call this function in loadTile, the results of getScreenSpaceError have already been cached in tile._screenSpaceError which gets computed in visitStart.

[lilleyse]

computeSSE caches but getScreenSpaceError doesn't, so this should be ok.

[pjcozzi]

Thanks for taking a look, @austinEng!

[pjcozzi]

@likangning93 could you please look at this in time for the release on Friday? Thanks!

[jbo023]

I checked with several of our datasets and didn't find any problems. The requests are now the same or less as they were before the traversal refactoring. With textured tilesets we see a good reduction in requests due to the skiplod level change.

[pjcozzi]

@jbo023 thanks for checking. @lilleyse please merge whenever makes sense for the release.