We are starting using cesium ion for some very large 3D meshes and we frequently notice freezes.
What we have is if we reduce MaxSimultaneoustimeload the freeze reduce greatly but the tiles load too slowly. We thought that MaxSimultaneoustimeload had very little impact on the UI thread but this does not seem to be the case. When many tiles are loaded simultaneously they all block the main thread
After code investigation it would seem there is a mechanism to limit the main thread usage by using the variable mainThreadLoadingTimeLimit in Tileset::_processMainThreadLoadQueue
However this is rendered ineffective by the fact that Tileset::LoadTileContent calls TilesetContentManager::postProcessContentInWorkerThread wich calls UnityPrepareRendererResources::prepareInLoadThread wich runs a lot of stuff in the UI thread
We don’t mind modifying the Unity Cesium library but we would like to know what motivates the fact of putting UI thread code in UnityPrepareRendererResources::prepareInLoadThread rather than _processMainThreadLoadQueue.
Hi @carlopiersanti, thanks for sharing all your investigation. Loading freezes are definitely not intended.
Here are some of my thoughts on the points you brought up…
_processMainThreadLoadQueue - This function handles the last parts of tile loading, where the game engine specific logic (Unity) can create its engine resources (Unity textures, meshes, etc)
mainThreadLoadingTimeLimit - Related to the previous function, this sets the maximum time budget we spend in processing main thread loads. So if it’s 5 ms, for example, we could spend at least 5 ms in _processMainThreadLoadQueue, but would kick any remaining work to the next frame, to try to preserve user frame rate (FPS)
Questions for you…
How many tilesets are you loading?
What kind of data are you loading, Cesium World Terrain? Google P3DT? your own?
What is your value for MaxSimultaneousTileLoads for each tileset?
It sounds like you are looking in all the right places, though. Just a matter of finding the source of the problem…
Thanks for your reply, here are the informations you asked :
In an example where we isolated the problem using only official Cesium assets (and that we can provide if you want) we have the following setup:
1 tileset created by putting in cesium ion a geotiff with only 0 altitudes to simulate the ground (imported as raster terrain), 20 simulataneous tiles load
1 tileset created by putting in cesium ion a 3D mesh hand made by a 3D modeler, 3D Model. Tile as 3D Tiles. Again we can provide the file if needed, 20 simultaneous tiles load
Both tilesets are loaded from hard drive without going trough network
In our opinion the problem comes from the fact that blocking code is run in the ui thread from the function prepareinloadthread wich is not rate limited
However it was only a superficial investigation
We are a bit hesitant to touch this since we assume that if you put ui code there there must be a good reason
TLDR, I think your building model (3D Tiles) is unoptimal, and needs to be regenerated.
1 tileset created by putting in cesium ion a 3D mesh hand made by a 3D modeler, 3D Model. Tile as 3D Tiles. Again we can provide the file if needed, 20 simultaneous tiles load
When viewed from far away, it’s almost 12 million triangles, and almost 16 million vertices. This is a lot of geometry for a distant object. When closer, it gets a little more detailed, but not very much. (PM’d you screenshots of Unity stats). This is most likely creating the loading hitches you are experiencing.
One of the goals of 3D tiles is proper handling of level of detail, and this model seems broken in this regard.
I would expect to see hundreds (or thousands) of verts / tris at far distances and millions of verts / tris at only the closest viewing distances. And even then, this should be tweakable with Maximum Screen Space Error (the smaller the value, the more detail presented).
