I’m importing 120 mesh objects from a .obj file and make a mesh imposter for each of them using the ammo js plugin interface. I used quad remesher to set the max quad count per mesh at 100 quads. The .obj file that contains all of the remeshed meshes is about 1.6 MB. Yet still I am getting an OOM crash from Ammo js. What are my options at this point?
Try using a different version of ammo. Ive seen people say the “ammojs-typed” package works.
I wonder if there is a vertex limit in ammo for a mesh collider? Can you console log the amount of vertices each model has before the OOM crash with mesh.getTotalVertices()?
2 Likes
i just had a thought. babylon doesn’t support quads, so maybe its trying to batch convert all the quads at once?
1 Like
Here’s a sample of the first 11
collisionMeshes[0].getTotalVertices()
4343
collisionMeshes[1].getTotalVertices()
130202
collisionMeshes[2].getTotalVertices()
72147
collisionMeshes[3].getTotalVertices()
37351
collisionMeshes[4].getTotalVertices()
72498
collisionMeshes[5].getTotalVertices()
33902
collisionMeshes[6].getTotalVertices()
37892
collisionMeshes[7].getTotalVertices()
86534
collisionMeshes[8].getTotalVertices()
53825
collisionMeshes[9].getTotalVertices()
86120
collisionMeshes[10].getTotalVertices()
38266
I’m glad you asked, because it looks like those number exactly match the un-remeshed meshes:
mapContainer.meshes[0].getTotalVertices()
4343
mapContainer.meshes[1].getTotalVertices()
130202
mapContainer.meshes[2].getTotalVertices()
72147
mapContainer.meshes[3].getTotalVertices()
37351
mapContainer.meshes[4].getTotalVertices()
72498
mapContainer.meshes[5].getTotalVertices()
33902
mapContainer.meshes[6].getTotalVertices()
37892
mapContainer.meshes[7].getTotalVertices()
86534
mapContainer.meshes[8].getTotalVertices()
53825
mapContainer.meshes[9].getTotalVertices()
86120
mapContainer.meshes[10].getTotalVertices()
38266
1 Like
My hunch is that you’re also correct on this. But I don’t think it’s what’s causing the OOM error directly. I do think it contributes though; the memory usage goes way up if I only load the .obj meshes but don’t actually let the physics simulation run. It won’t crash however.
To help isolate the source, this might help:
If you check this PG out, I find that I hit the OOM limit when the NUM_SEGMENTS gets > 60. For reference, I am generating a mesh based on an array of a few thousand points (see the URL’s at the top of the PG for reference).
Tweak NUM_SEGMENTS up and down to see effects; cut in half the number of data points by un-commenting line 32
HTH!
1 Like
Did you try ammojs-typed - npm ? There are a few things trying it can rule out. First, its a version that users have reported to work, when newer versions of ammo are breaking. It’s also javascript only, which can maybe rule out wasm memory problems due to bad emscripten options.
If you check this PG out
There’s a memory leak on that page. If I keep trying to change the value of NUM_SEGMENTS, and then hit play, eventually I won’t be able to run it at any value of NUM_SEGMENTS without getting the OOM error. I have to refresh it in order to test each value. Because it already initializes once on page load, and that memory never gets released, I get the OOM error even when setting the NUM_SEGMENTS value to 46.
But what is this all showing me exactly?
I have not. I was already using the package just for the ammo js typescript support. I’ll try using it as the actual Ammo JS import / build right now and report back.
Interesting – I’m not getting the same memory leak behavior you are, but there’s a lot of reasons why that might happen 
I DO however get the OOM above 16 or so segments - it will depend on how many data points are sampled, natch.
What is the point of it? Well, I was hoping that knowing that it seems to be OK handling 121,528 faces / 50,792 vertices at NUM_SEGEMENTS = 14 would be a helpful data point - apologies for wasting your time if it was not.
1 Like
Can you create the mesh collider for other meshes but the one with 130202 vertices?
1 Like
Still happening, using import Ammo from 'ammojs-typed'
I’m questioning the output from the quad remesher program, since those vertices are still in the thousands.
No its not a waste of time!
I just wanted to be clear what exactly I was testing. I think I can use your line of thought here to come back with an answer at exactly how many vertices I’m using.
function totalVert(meshes) { t = 0; meshes.forEach((m) => t += m.getTotalVertices()); return t }
undefined
totalVert(mapContainer.meshes) # my original meshes
650702
totalVert(collisionMeshes) # what I tried using as a "fix" since I had set the quad count to 100)
5199060
This makes me think I’m using the quad remesher tool wrong.
1 Like
@Panuchka @jeremy-coleman @jelster Do any of you know what to expect in terms of the total vertices for each mesh when using a tool to reduce their quad count? My initial assumptions were that there should be less vertices and a smaller raw file size.
babylon has a few builtin tools that can help
i think this is the most basic pg showing mesh decimation (the camera is slow to start while the work is happening)
docs here
.Simplifying Meshes With Auto-LOD | Babylon.js Documentation
and here
.The Scene Optimizer | Babylon.js Documentation
idk if doing it in babylon ahead of time could be easier ?
2 Likes
I’ve always liked this tool
(github repo here GitHub - stephomi/sculptgl: DEVELOPMENT STOPPED I'm now working on Nomad Sculpt instead )
on the right under topology you can play with subdividing and decimating. the top right of the screen there is a total count of verts
1 Like
That’s a tough one to ballpark out I think, because I think it will depend a lot on whether the tool is able to create/associate shared vertices as opposed to creating new vertices.
Something else I realized is that my face count is doubled, since I’ve got it marked as DOUBLE_SIDED – maybe you can reduce the load by specifying single-sided?
1 Like
Sorry I didn’t see your response.
I just tried the following:
const LIMIT = 100000 collisionMeshesContainer.meshes = collisionMeshesContainer.meshes.filter((m) => m.getTotalVertices() < LIMIT)
totalVertices = 4743308
still errors.
I also tried:
LIMIT = 10000, totalVertices = 63730, no OOM errors.
LIMIT = 50000, totalVertices = 1352248, has OOM error.
cc @Cedric