Open Maksims opened 4 years ago
Thanks, this does sound like a bug. I opened https://github.com/emscripten-core/emscripten/issues/9854 in emscripten, with an idea for how to avoid it.
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.
Sorry for offtopic, but 10k physical objects, is definitely an overkill for a web browser. With such numbers of objects and triangles, you will want to move towards native platforms, and think of optimising an approach. As even for native, it will be a struggle.
Sorry for offtopic, but 10k physical objects, is definitely an overkill for a web browser. With such numbers of objects and triangles, you will want to move towards native platforms, and think of optimising an approach. As even for native, it will be a struggle.
Thank you for your reply. It seems that I can only use game like solutions to solve physical simulation on BIM..
Sorry for offtopic, but 10k physical objects, is definitely an overkill for a web browser. With such numbers of objects and triangles, you will want to move towards native platforms, and think of optimising an approach. As even for native, it will be a struggle.
Hi, I solved my problem and made sure the frame rate of both the renderer and the physical engine is 60. For non wasm versions. That is, the ammo.js file. Before importing ammo.js, add the statement "var Module = {TOTAL_MEMORY: 512 1024 1024};" to allocate the total memory. In the official case, it seems that modifying the total memory has no effect, and the memory still leaks. So I modified the ammojs file and added the code: "d.TOTAL_MEMORY = Module ? Module.TOTAL_MEMORY : null;" and then I succeeded. I hope I can help you. In addition, for bvhtrimesh, if too many physical engines are created, the frame rate is relatively low. But if you combine the mesh into one, even millions of vertices and triangles, the physics engine on my laptop is still 60 frames.
We've been using ammo.js in https://github.com/playcanvas/engine and recently I were going through some memory leaks related to ammo.js. Everything has to be manually cleared, but there are certain references left in ammo.js
__cache__
objects.Here are few examples:
creating btRigidBody, then get use
getMotionState
on it. ThenAmmo.destroy(body)
, but motionState will remain inAmmo.btMotionState.__cache__
. CallingAmmo.destroy(state)
on it, will throw an error, as I would assume it is actually destroyed already with body, but reference still in present.Creating btCollisionShape, of different types, like
btBvhTriangleMeshShape
. CallingAmmo.destroy(shape)
removes shape, but leavesbtBvhTriangleMeshShape
inAmmo.btBvhTriangleMeshShape.__cache__
.btDefaultMotionState
, when relatedbtMotionState
is destroyed, it does not remove relatedAmmo.btDefaultMotionState__cache__
.Calling
manifold.getBody0
ormanifold.getBody1
, will returnbtCollisionObject
, but then references to it, never removed as well, when that object is eventually destroyed byAmmo.destroy(rigidBody)
.How do we properly remove those related
__cache__
references, when their actual objects are destroyed internally? Doing:delete Ammo.btBvhTriangleMeshShape.__cache__[shape.ptr];
seems very hacky.