firstly, I want to extend huge props to @brendan-duncan and the rest of the Cesium dev team. The fact that you got Cesium running under WebGL feels like a miracle to us.
As such, we have now started evaluating the possibility of moving some unity-webgl based customer software from a competitor to Cesium.
Currently, we are experiencing an issue with RAM accumulation, caused by 3d-tiles and their data being retained in memory instead of being unloaded over time / as other parts of the model are culled away.
Basically, when flying over larger tilesets, the stored data accumulates to an extent where it eventually crashes the browser.
Note: we not only need to deploy to WebGL, but also… mobile WebGL… and even worse… mobile WebGL on iPhones . So our memory budget is …. rather small.
I have read through several forum threads and a few open issues on GitHub and came across this ticket.
From it, a assumption arises that on the web the SQLite database is probably living in memory. Changing the values of CesiumRuntimeSettings, however, does not seem to have any effect on the described behaviour.
It’s true that we don’t expose a way to set the overall size of the cache, but you should get the same effect if you set the Maximum Cached Bytes on all your Cesium3DTilesets to zero. Have you tried that out?
Thanks for your reply. I have in fact tried that out. Through further profiling I have also found out that its not necessarily a problem on the Unity side of things. It seems memory there is released properly.
My working theory is that this might perhaps be a memory leak in Cesium-Native on the web. Or perhaps, it is just silly JavaScript behaviour…
I have taken a screen capture, for better understanding.
As you can see, the memory inside Unity is under control. In fact I have capped the max memory for the WASM Language Feature at 1024 (which is never reached). On the Browser side however, the total JS Heap Size quickly climbs beyond 4GB.
I wrote an issue to disable the CachingAssetAccessor when running on the web. I’m not sure if it’s the cause of the memory growth you’re seeing, but it’s certainly unnecessary in any case.
. So our memory budget is …. rather small.