Ammo OOM when creating new mesh colliders runtime.

[Kangsi]

Description

In this example project there are several meshes colliders, which you can adjust by dragging the pointer. All vertices and faces within the radius of the pointer are removed. Each time an adjustment is made, the mesh entity is destroyed and a new entity is generated, where the new mesh is applied. So the user can create a path for the ball to move from the top to bottom by dragging the pointer.

However, when creating too many meshes, Ammo will be out of memory. In my case it's around 3500 generated meshes.

We expect that the reference of the old mesh collider will be removed from the Ammo cache by destroying the entity. In this example we destroy the whole entity and create a new one, so all references to the old mesh are removed. We also tried to just update the mesh collider instead creating a new entity, but it didn't show any differences.

Example Project: https://playcanvas.com/project/658302/overview/sand-mesh-generation-memory-leak

Steps to Reproduce

1. Drag the pointer to adjust the meshes.
2. Keep dragging and check the logs.
3. Eventually Ammo will get OOM.
4. Reset the meshes if required.

[willeastcott]

Hey @Maksims - can you take a look please?

[Maksims]

After some investigation:

1. You are forgetting to destroy custom model you are creating for each new generated mesh entity. https://playcanvas.com/editor/code/658480?tabs=26684900,26684910
2. Each time you attach model to collision component, you trigger TriMesh generation. Ammo does not garbage collect its objects. So you have to manually destroy TriMesh you are not reusing after. https://playcanvas.com/editor/code/658480?tabs=26684900,26684910

For more convenient destroying of TriMesh, I've created new PR #1806.

Thank you for reporting an issue and replication project!

[Kangsi]

Hi @Maksims ,

Thank you for the fast reply and your explanation. We applied the changes to the replication project.
It seems to be improved, however there is still a leak somewhere. Ammo crashes around 7500 generated meshes instead of 3500. The TriMesh cache is stable now. Is the issue related this one? kripken/ammo.js#284

[Maksims]

It could be, but there are some leaks that are related to the way Emscripten handles its cache.

[Kangsi]

Since the latest build (v1.24.4) the error no longer occurs.

[lm165678]

Hi, can someone help me? When I use ammo to create a large number of btbvhtrianglemeshshapes, if the number of meshes is too large, I will report oom. But I don't know how.

I have 10473 solid objects, 877308 vertices and 292436 triangles. I hope to solve this problem without reducing the number of grids, because this is a BIM project.

When creating the btbvhtrianglemeshshape of the 7000th entity, it will report oom. When you directly treat the whole scene as a btbvhtrianglemeshshape, it will directly oom. So I divided it into more than 10000 btbvhtrianglemeshshapes.

Thank you

[slimbuck]

Hi @lm165678,

The build of ammo.js provided by playcanvas editor (the files you get when you click 'import ammo' button) is just the default build of ammo, which is configured to use a fixed 64MB block of memory. You can see the configuration in the official repo at https://github.com/kripken/ammo.js/blob/master/make.py#L76.

It it possible to compile your own build of ammo with increased memory and/or enable memory growth. (Though enabling memory growth slows things down). You can then use these modules in your project instead of the defaults. For more information on configuring wasm modules in playcanvas take a look at https://developer.playcanvas.com/en/user-manual/assets/wasm-modules/.

You may find that compiling modules is a bit complicated though and ideally playcanvas would allow users to specify the memory allocation per project.

You are welcome to log a feature request for per-project memory allocation at https://github.com/playcanvas/editor if you like.

Thanks!