Why does loading certain 3D Tiles services in Cesium take so long, and is there a maximum size limit for the cache file?

Cesium for Unity
1

Hello everyone,

I am encountering some performance issues when loading multiple 3D Tiles services in Cesium and have questions regarding the cache mechanism. I would appreciate any insights or suggestions.

Here are the details of my problem:

  1. **Ineffective Cache Behavior:**​ I have set cesium3DTileset.maximumCachedBytes = 53687091200(50 GB) for my tilesets. However, when I move the camera away from a specific area and then return to it, the 3D Tiles data for that location reloads slowly from the beginning, instead of being quickly retrieved from the cache as I expected.

  2. **Simultaneous Loading of Multiple Tilesets:**​ My scene contains five 3D Tiles services. I’ve noticed that when the camera is at a lower altitude and the view frustum encompasses only one of these services, the model for that service loads immediately. However, I am concerned about the potential performance impact when the camera view includes multiple services at once, causing them to load concurrently. Will the simultaneous loading of multiple tilesets significantly affect loading efficiency or cause performance bottlenecks?

  3. **Cache File Size Limit:**​ I observed that the Cesium disk cache file on my C drive, named cesium-request-cache.sqlite-wal, has grown to about 24.8 GB. **Is there a maximum size limit for this specific WAL file?**​ If so, what determines this limit, and is it possible to adjust it?

Has anyone experienced similar issues or have suggestions on how to optimize the loading performance and cache utilization in this scenario? Thank you in advance for your help!

2

Hi @jh007, I’ll try to answer your questions.

Ineffective Cache Behavior

That maximumCachedBytes number is pretty huge and very likely to cause you to run out of memory and crash. But I’m surprised it’s not letting you revisit an area without reloading tiles, and I can’t reproduce this problem. Here’s how I tested it…

I opened the Cesium for Unity Samples project and then opened scene 07_CesiumGoogleMapsTiles and hit Play. Then I alternated between pressing 1 and 2 to fly back and forth between two locations.

With the maximumCachedBytes at its default size, each time I flew to the other location the LOD started low and then increased. It increased pretty quickly because the tiles were still in the disk cache, but the memory cache was too small to keep them resident.

I then increased the maximumCachedBytes property to 10737418240 (ten times larger) by clicking the Google Photorealistic 3D Tiles game object in the Editor and changing it using the Inspector. Play mode was still running.

Now when I switched between location 1 and 2, the detail at each location was immediately visible, with no LOD shift. So the cache seems to be working correctly.

If you believe it’s not working on some cases, perhaps you can share some step-by-step instructions so I can reproduce this myself? Preferably starting with the Cesium for Unity Samples project.

Simultaneous Loading of Multiple Tilesets

Yes, multiple tilesets loading simultaneously will surely compete for resources, such as:

  1. Network bandwidth to download tiles,
  2. CPU time to decode images, create physics meshes, and more,
  3. GPU time for rendering as well as bus bandwidth for uploading meshes, textures, etc. for rendering.

Internally, TilesetViewGroup has a “weight” property that can be used to give more priority to some tilesets over others. It’s not exposed through Cesium for Unity yet, though.

Cache File Size Limit

The disk cache doesn’t have a size limit, but it does have a limit on the maximum number of requests it stores. Unfortunately, it is only pruned down to this size after a certain number of requests. Especially when we’re developing our applications, and we run for only short periods of a time to test things, this can cause the cache file to grow quite large. This problem is described here:

The WAL file specifically growing large can indicate a different problem, though. It could be that two processes are accessing your database simultaneously. For example, the Editor and a Player, or two running copies of a Player. Or even the command-line sqlite3 app. SQLite doesn’t handle this particularly well, and it can cause the WAL file to grow quite large because it’s never able to commit the changes back to the main database.

When in doubt, you can simply delete the request cache.