Hello everyone,
when I use dispose on meshes that I want to remove it doesn’t free the memory. E.q. I load one model and it consumes 4gb of ram. When I remove it I expect memory to go back to normal (like 1,5gb usage). Unfortunately when I dispose this model it still consumes 4gb so when I load another one it takes another 4gb and then webgl is crushing.
dispose() shouldn’t free the memory?
No, the memory is disposed by the browser whenever it sees fit. However, if at some point it needs more memory than available but can free some, it should do it with a garbage collect.
If it doesn’t do it in your case, it may be because you still have some references to your meshes somewhere, preventing the browser to reclaim the memory.
The purpose of dispose() is to free gpu resources. Cpu side stuff first needs to go out of scope, then will be a candidate at the next gc.
Not only GPU resources. It also serves to release internal “pointers” so that the memory can be reclaimed later by a GC (see for eg scene.dispose).
Yeah, I was mostly just filling in around your answer. Was on a tablet at the time, so I limited my words.
I have actually have been thinking of even nuking the references to any unpinned / non-update-able vertex data, when the mesh is first ready. Get it queued to be dropped early. It never gets used again, except for perhaps any mesh info calls like getTotalVertices(). Obviously cannot use dispose() itself for this.
Not high on my priority list though. More of a production deployment step. Nuking matrix indices & weights would obviously kill animations if cpu skinning was downgraded to, but that is almost an early warning feature telling you something needs to change.
Not sure if there is a way to tell if a piece of vertex data was updateable, but I can just check if there are shapekeys (for cpu based morphing) in the Mesh subclass I use.
Please note, that most of the time the memory is coming from textures and not directly the meshes so when disposing mesh only you would not collect back the textures memory. You would need to either dispose the materials and textures as well or call:
dispose(true, true);
to first do it recursively and second force disposing associated materials and textures.
Big reason to use compressed textures, in addition to access time / cache. Memory access time is the new I/O bottle neck, assuming that you are pixel shader bound.
cpu styles textures (.jpg / .png) are pigs.
dispose(true, true) @sebavan worked, thank you very much and every other for explaining the babylon
I don’t know if this is an issue, but be careful with dispose(true, true). If you have multiple meshes pointing to the same materials/textures, calling dispose(true, true) on one mesh will also dispose the materials/textures in use by the other mesh.
I suppose that wouldn’t happen if the material is a clone of other material?
I’m not totally sure. I think if you have textures, a cloned material will point to the same textures.