Distance tile load setting

Manc_Dan · June 1, 2023, 8:33am

It would be useful if there was some way of defining how many tiles load in from from your viewpoint/camera (in M/KM?). This would help with bandwidth, load times, quota longevity and improve performance etc.

Looking through the settings I’m not sure if there is a way to already do this? Is there>?

Many thanks

Kevin_Ring · June 1, 2023, 11:18pm

There’s currently not a way to do this. We often get this request, but it would be much less useful than people think. The reason is twofold.

First, it wouldn’t reduce bandwidth and load times as much as you might expect. Because of 3D Tiles’ hierarchical LOD structure, tiles in the distance are bigger and lower resolution, and there are far fewer of them. So skipping them entirely would only reduce the total number of tiles a little bit. It wouldn’t make a big difference.

Second, setting a distance in M/KM wouldn’t actually work that well. The view distance you need is highly dependent on the camera height. For applications with a fixed camera height you might get away with it, but most applications have a mix of near and far views, so a single view distance wouldn’t work.

Internally, cesium-native has a thing called a fogDensityTable:

github.com

CesiumGS/cesium-native/blob/main/Cesium3DTilesSelection/include/Cesium3DTilesSelection/TilesetOptions.h#L212


      
           * density. Tiles that are in full fog are culled. The density of the fog
           * increases as this number approaches 1.0 and becomes less dense as it
           * approaches zero. The more dense the fog is, the more aggressively the tiles
           * are culled. For example, if the camera is a height of 1000.0m above the
           * ellipsoid, increasing the value to 3.0e-3 will cause many tiles close to
           * the viewer be culled. Decreasing the value will push the fog further from
           * the viewer, but decrease performance as more of the tiles are rendered.
           * Tiles are culled when `1.0 - glm::exp(-(distance * distance * fogDensity *
           * fogDensity))` is >= 1.0.
           */
          std::vector<FogDensityAtHeight> fogDensityTable = {
              {359.393, 2.0e-5},     {800.749, 2.0e-4},     {1275.6501, 1.0e-4},
              {2151.1192, 7.0e-5},   {3141.7763, 5.0e-5},   {4777.5198, 4.0e-5},
              {6281.2493, 3.0e-5},   {12364.307, 1.9e-5},   {15900.765, 1.0e-5},
              {49889.0549, 8.5e-6},  {78026.8259, 6.2e-6},  {99260.7344, 5.8e-6},
              {120036.3873, 5.3e-6}, {151011.0158, 5.2e-6}, {156091.1953, 5.1e-6},
              {203849.3112, 4.2e-6}, {274866.9803, 4.0e-6}, {319916.3149, 3.4e-6},
              {493552.0528, 2.6e-6}, {628733.5874, 2.2e-6}, {1000000.0, 0.0}};
          
          
/**
           * @brief Whether to render tiles directly under the camera, even if they're

It’s a bit inscrutable, which is why we haven’t exposed it up through Cesium for Unreal, but the basic idea is that objects that are really far away don’t need to be rendered, and the meaning of “really far away” is a function of camera height. So potentially tweaking that could help achieve your goal. But again, the gains to be had here are quite modest. I’d roughly estimate you could achieve maybe a 10-20% reduction in tile loads by bringing in the view distances, not more than that. And at the cost of having mountains vanish in the distance.

Manc_Dan · June 2, 2023, 8:57am

Ok, thanks understood.

I have a camera orbiting around a city centre, how can I ensure tiles are loaded in time (at the required screen space error setting) so that when the camera moves around buildings are loaded in correctly?

Kevin_Ring · June 2, 2023, 12:45pm

There’s no perfect answer to that. If you’re trying to record a video, just make sure you use UE’s Sequencer. It will automatically make sure all tiles are loaded for a frame before it snaps the frame.

But if it needs to be interactive, the best you can do is try to warm up the cache. Set the Maximum Cache Size Bytes property larger so that tiles don’t get unloaded (but not so high that your GPU runs out of memory), and then fly around letting tiles load. Revisiting those same areas again will then be much faster.

There’s also a disk cache, and warming that up will make a big difference. But unfortunately it currently isn’t helpful for the Google photogrammetry tiles (if you’re using those), because of the unusual cache header returned by the Google tiles. More details about that are here:

github.com/CesiumGS/cesium-native

Add basic support for `stale-while-revalidate` cache control header

opened 03:32AM - 01 Jun 23 UTC

kring

enhancement

The new Google 3D Tiles include a cache header like this: ``` Cache-Control:… private, max-age=0, stale-while-revalidate=86400, no-transform ``` cesium-native currently treats this as totally uncacheable, due to the `max-age=0`. But actually the header says "you can use the cached response for 24 hours, but you should also, in the background, revalidate it." Implementing this exactly as the spec says is somewhat complicated, due to the need to return a result _and then also do the request_. And the value is dubious because that revalidation request competes with other requests for content, making the theoretical lower latency unlikely to really pan out in practice. But there is one way in which this header is clearly better than "no caching at all." It allows the response to be stored in a cache and then, when we later request it again, we can include the `If-None-Match` header with the cached Etag. If they match, the server can respond with a 304 code and an empty response. This still requires a round-trip to the server (which is the bulk of the time in some environments), but doesn't require the actual data to be downloaded again. On slower connections, at least, this can be a pretty good win. And we can add support for it pretty easily, without any of the complexity of the deferred revalidation that `stale-while-revalidate` suggests. In fact, we should be able to do this Etag-based validation in a wide variety of cache header contexts, not just `stale-while-revalidate`.