Dynamic meshes create a memory out of bounds in Unity WebGL in a CAD project

Currently WebAssembly in Firefox and Safari browsers has a limitation that one can in the best scenario only allocate 2GB for a WebAssembly heap. In Chrome one can allocate a maximum of 4GB of heap memory. There is no theoretical limit for GPU memory, so if you are loading the meshes only to GPU memory, and delete them from CPU memory afterwards, then theoretically it could work.

For WebGL applications this memory limit means that you can reliably get to probably around 1.5GB-1.8GB of C# memory usage at most (random estimating a ~200MB+ block being taken by Unity engine)

Also be aware of the pregenerated .data file on disk: this file will eat up CPU memory as much as the .data file is in size. For most efficient memory usage, avoid loading assets in the initial .data file, but use separate asset bundles to load in assets. That way they can be loaded at runtime (and then discarded) without a persistent startup memory cost.

Also try disabling Data Caching, I have a gut feeling that it might cause additional memory usage for files on disk.

Unfortunately WebGL API has overhead compared to native OpenGL with rendering very large amounts of objects, that is due to security validation and sandboxing reasons.

Ideally in such large memory usage cases, Unity would prefer to show a better error message than "memory out of bounds". That error means (in this context) that Unity did not catch some error in memory allocation, but then the underlying WebAssembly VM failed.

Maybe in this case I would try to find models that are at the limit of breaking, and use that to estimate max size limits for the application on the web. Then see if there are any ways to squeeze the memory usage optimization even higher.

Another way to try to find opportunities to optimize is to look for parity issues between native Windows/macOS builds versus WebGL builds. For example, for such a build that is at the limit of breaking WebGL (but just barely still works), do memory profiling to see how much memory is consumed. Then do the same profiling on native Windows build. If those have a large discrepancy, then we might expect there to be something WebGL specific that we could optimize.

If those come out largely the same, then we would be looking for a platform agnostic way to optimize.

If the project is small/manageable in complexity (or can be reduced to a small test case with large memory usage at that "breaking limit"), I'd be curious in seeing it in action to see if there's anything to spot.