hi, I use CesiumForUnity to view global image data, in platform Windows, everything is fine.but in webgl,report error OOM, I upload screencapture,How can I optimize this?
Hi yuzhe. Thanks for writing.
Since WebGL has much stricter memory limits than desktop builds, I wonder if any of these could help:
Increase Maximum Screen Space Error on your Cesium3DTileset component. A higher value will load fewer, lower-detail tiles and should reduce peak memory usage.
Lower Maximum Simultaneous Tile Loads to reduce how much data is in flight at once.
Increase WebGL heap size. If I recall correctly, you can set this in Unity Player Settings > Publishing Settings > WebGL Memory Size.
Let us know if any of those solutions work. If not, we can take a deeper look.
Running Cesium for Unity in WebGL is a new effort that comes with new challenges. Thanks for reporting the issue!
thanks for your reply.I reduce maximumCachedBytes and **maximumSimultaneousTileLoads,**the memory has indeed decreased,but webgl still report OOM error sometime.my data is global imagery data, all over the world. The memory usage will increase when I browse more areas.So I must call RecreateTileset at certain times to release memory.
Very interesting workaround calling RecreateTileset. I will try this next week. Perhaps this can help me out a lot.
I have opened a thread in regards to the same issue a while back:
resulting in @Kevin_Ring opening this issue on GitHub.
After further investigation and talking to some devs at Cesium Con about this, I think the issue described in GitHub is not the main source of this behaviour.
@adam_morris pointed me towards how WASM manages memory.
WASM memory using Unity’s WebGL Diagnostic Tools seems fine however (it uses between 200-500mbs for me). It is the JavaScript Heap itself that causes this issue, growing infinitely.
(It might still be related to WASM - I am far from an expert when it comes to this. I just wanted to share the observations I made in the meantime.)
@hv_nico
Thanks for join this discussion. It seems we’ve both encountered memory issues. In my case, calling RecreateTileset method did work, and I believe it will work for you as well.
However, this method has a drawback: it clears your interface and reloads it, which is not user-friendly. And I hope you can let me know the results of your try. Thank you.
A fix would be awesome as this heavily affects our production app and affects the user experience.
A fix would also be great for us, as RecreateTileset is not an option given the impact on user experience. We are experiencing “holes” in the 3D Tiles block display after viewing large areas, most likely due to a memory runaway on models that are easily handled by the Windows, Android, and iOS versions.
@Cory_Barr It seems many people have encountered issues with WebGL memory. What progress has been made on this issue?
Hi @yuzhe
You’re right. We’re hearing reports of WebGL memory issues from various sources. We have some time in July planned to take a look at the various WebGL memory reports and see what can be done on our end. I’ll make a note to update this thread with any findings. Thanks!
Here is Claude’s observation regarding this issue:
On a multithreaded Cesium for Unity WebGL build, performance.memory.usedJSHeapSize (main-thread-only) drastically undercounts actual memory — in one test it read ~0.3 GB while performance.measureUserAgentSpecificMemory() (which includes Worker threads) read ~2 GB for the same moment. This confirms the growth is happening in the Worker thread(s) doing the actual tile/engine work, not the main thread — so any diagnostic relying on performance.memory alone will badly underreport the problem.
RecreateTileset() helps but doesn’t fully reclaim: it’s the documented mitigation, but it re-downloads all visible tiles (its own temporary spike) and empirically doesn’t bring memory back to baseline — suggesting something is retained independently of the tileset object lifecycle.
Separately: the wasm linear memory itself is expected to never shrink once grown (memory.grow is one-directional per the WebAssembly spec) — that’s a real ceiling worth designing around, but it’s a different issue from the JS-heap growth above and shouldn’t be conflated with it in the fix.
It also has a suspected root cause, but it’s most likely just quoting the forum threads.: CachingAssetAccessor — cesium-native’s SQLite-backed HTTP response cache. It’s redundant in a browser (the browser already caches HTTP responses) but, unlike the tileset itself, isn’t tied to RecreateTileset()'s lifecycle — so it would keep accumulating regardless of how often tilesets are recreated. Worth confirming whether this is compiled into WebGL/Emscripten builds, and whether excluding it under EMSCRIPTEN changes the growth curve.
hi, @Cory_Barr i want to know have new progress in memory issue?
It seems like some time has passed, and I want to know have any progress on this issue? I also welcome more people to join the discussion.
Hi,
We are also waiting for a solution to this issue, as the memory runaway prevents production use of the WebGL build.
We’re also affected by this, excessive memory consumption in the WebGL build makes it unusable for us.