Autorender loop issues

[gberaudo]

Autorender loop is currently broken.
Below we list known issues:

• 204 responses
  Receiving a 204 is an error for the Cesium image loader (a simple browser image).
  Some top level tiles get marked non renderable, which increases tilesWaitingForChildren.
  This prevents the render loop to stop;
• broken upsampled terrain
  Broken terrain (see South west of switzerland is missing in 3d  #2872 (comment))
  when upsampling will throw an exception which will end in the tile marked failed. This will
  increase tilesWaitingForChildren preventing the render loop to stop.

[loicgasser]

Starting from level 12 gaps are produced by topo and it's known issue and will be solved.

I will check the occlusion point as well, do you have a tile address where you know there is a problem with the occlusion point?

Regrading raster, to make sure I understand correctly, you mean that a single 204 error in a top level tile will break the autorender loop? Again do you have an exemple of such a case?

[gberaudo]

Here is the list of errors I get for level 8:

Cesium.js:29529 An error occurred in "UrlTemplateImageryProvider": Failed to obtain image tile X: 271 Y: 62 Level: 8.
Cesium.js:29529 An error occurred in "UrlTemplateImageryProvider": Failed to obtain image tile X: 271 Y: 61 Level: 8.
Cesium.js:29529 An error occurred in "UrlTemplateImageryProvider": Failed to obtain image tile X: 271 Y: 60 Level: 8.
Cesium.js:29529 An error occurred in "UrlTemplateImageryProvider": Failed to obtain image tile X: 270 Y: 60 Level: 8.
Cesium.js:29529 An error occurred in "UrlTemplateImageryProvider": Failed to obtain image tile X: 264 Y: 60 Level: 8.
Cesium.js:29529 An error occurred in "UrlTemplateImageryProvider": Failed to obtain image tile X: 269 Y: 59 Level: 8.
Cesium.js:29529 An error occurred in "UrlTemplateImageryProvider": Failed to obtain image tile X: 271 Y: 59 Level: 8.
Cesium.js:29529 An error occurred in "UrlTemplateImageryProvider": Failed to obtain image tile X: 266 Y: 59 Level: 8.
Cesium.js:29529 An error occurred in "UrlTemplateImageryProvider": Failed to obtain image tile X: 267 Y: 59 Level: 8.
Cesium.js:29529 An error occurred in "UrlTemplateImageryProvider": Failed to obtain image tile X: 268 Y: 59 Level: 8.
Cesium.js:29529 An error occurred in "UrlTemplateImageryProvider": Failed to obtain image tile X: 270 Y: 59 Level: 8.
Cesium.js:29529 An error occurred in "UrlTemplateImageryProvider": Failed to obtain image tile X: 264 Y: 59 Level: 8.
Cesium.js:29529 An error occurred in "UrlTemplateImageryProvider": Failed to obtain image tile X: 265 Y: 59 Level: 8.

For example: https://wmts6.geo.admin.ch/1.0.0/ch.swisstopo.swisstlm3d-karte-farbe.3d/default/20150501_50/4326/8/59/264.jpeg

In the code below, the tiles are not renderable (missing imagery) thus
tilesWaitingForChildren is incremented.

        // Enqueue the root tiles that are renderable and visible.
        for (i = 0, len = levelZeroTiles.length; i < len; ++i) {
            tile = levelZeroTiles[i];
            primitive._tileReplacementQueue.markTileRendered(tile);
            if (tile.needsLoading) {
                queueTileLoad(primitive, tile);
            }
            if (tile.renderable && tileProvider.computeTileVisibility(tile, frameState, occluders) !== Visibility.NONE) {
                traversalQueue.enqueue(tile);
            } else {
                ++debug.tilesCulled;
                if (!tile.renderable) {
                    ++debug.tilesWaitingForChildren;
                }
            }
        }

[gberaudo]

The occlusion point issue appears when creating upsampled tiles at level 13 from data of a tile level 12.
I guess this is the topo issue you mentioned, see #2872 (comment).
My understanding is that the upsampled occlusion point is undefined because no vertex from the level 12 tile fall in these target level 13 tiles.

[loicgasser]

BGDI tilegenerator related config is:
https://github.com/geoadmin/bgdi-tilegenerator/blob/master/etc/tilecache.swisstopo.4326.cfg

Per default for TMS Cesium defaults origin is at top or at bottom? Terrain tiles have their origin at bottom for instance, these ones at top.
The only way to completly avoid these errors is to add the correct layer config for these layers. I had a hard figuring out what was the issue and why I couldn't get a correct config with this layer so far. I will see @ltclm tomorrow.

[gberaudo]

@loicgasser, I do not have access to this project.
The imagery tile grid coordinates matches the coordinates displayed in the Cesium inspector.
X is going left to right and Y is going top to down.

[gjn]

For my understanding: if we disable autorenderloop, it won't have any impact on amount of data transfered, correct?

[fredj]

For my understanding: if we disable autorenderloop, it won't have any impact on amount of data transfered, correct?

This is correct

[gberaudo]

The autorenderloop is designed to reduce the amount of CPU and GPU consummed by Cesium.
It should not impact the amount of data transfered.
Failing to stop is equivalent to being disabled: Cesium will consume the maximum of CPU and GPU resources.

[cedricmoullet]

@gjn how do we proceed on this issue ?

[gjn]

@gberaudo This is still an issue, correct?

[gberaudo]

Yes

[davidoesch]

ping @gberaudo @loicgasser update on this? Still an issue ?

[loicgasser]

No, not to my knowledge. @gberaudo can probably confirm.

[gberaudo]

It is still an issue:

• open the main page;
• switch to 3D;
• wait for a long time without any action (eg. 30s).

The CPU consumption stays at 100%.

[loicgasser]

Well the top levels raster tiles simply don't exist for zoom levels 0 to 7.

Also for terrain we're not using all zoom levels, I don't know how this may affect the autorender loop.
https://github.com/geoadmin/mf-geoadmin3/blob/master/src/components/map/MapService.js#L595

We also constrain the min LOD:
https://github.com/geoadmin/mf-geoadmin3/blob/master/src/components/map/MapService.js#L680

Based on:
https://github.com/geoadmin/mf-geoadmin3/blob/master/src/components/map/MapService.js#L1376
Maybe that's where the problem is. The TODO there..

We currently don't provide a resolution array for native raster layers in 4326.

Best would be for to tell cesium the root tiles start at zoom level 8 and not 0 so maybe adapt the function above.

https://3d.geo.admin.ch/imagery/layer.json

As a side note I can't observe:
Cesium.js:29529 An error occurred in "UrlTemplateImageryProvider": Failed to obtain image tile...
anymore.

@gberaudo thoughts? Do I understand the problem correctly?

[oterral]

I think the only problem now is the 204 tile's response. The broken upsampled terrain stuff has been fixed.

[gberaudo]

Let's try to fix the issue with 204s.

[loicgasser]

We probably need to Patch Cesium and tell him not to try to render tiles with no content endlessly. Or change responses at Varnish / Cloudfront level, which is a more sensitive topic.

[oterral]

I finally understand what's happening.

At the beginning Cesium creates a set of tiles representing the first terrain level we load. In Cesium that creates the 2 tiles at level 0 but with our modifications that creates a set of tiles at level 8, see .

This set of tiles is created from the tilingScheme not from terrain metadata file so that creates a square bigger than the ranges defined in the metadata file.

So there is exactly 31 tiles which are out of ranges and they block the dequeuing.