Questions on Recast-detour memory management

I have a question about memory management on RecastJS from the BabylonJS/extension.
Maybe @Cedric, you are the best person to answer my questions.

I use your RescastJS on a game I develop without Babylon. The game have multiple scenes. Each scene are load individually, and are build with some procedural part.
Currently at each scene start, I create a Recast object to generate a fresh navmesh. At the end of the scenes, I use dispose() and unlink the recast object to be destroy with the garbage collector.
After I reload 12 times my level or load other, I have a OOM and rescast don’t want to be recreate.

I searched for documentations and I dug in the code but I did not find information about how to properly destroy recast and correctly free the memory.
I saw some __cache__ items in Recast that they are not free between scenes, maybe other data are also keep.

So, my questions :

  • Recast with Emscripten it is designed to be destroyed or to be use as none-destroyable singleton ?
  • If Recast can be destroyed, How to correctly free all the memory ?

Sincerely, Julien.

Hi @j.b and welcome to the forum

The recast plugin is meant to not be destroyed. Yes, it can be viewed as a singleton.

Without creating a crowd, do you still experience the OOM?

Do you call navmesh.destroy() once you are done witht it?

Hello @Cedric,
Thank you so much, with your response I understand much more what happen. At the end of my digging in the code, I had serious suspicions that I done something not right.
So no destruction and one instance of Recast, got it.

When I destroy the scene to load the next, I call Recast.navmesh.destroy() and Recast.dispose().

I tested without crowd instantiation. I have OOM again but later, about 18 reload.

At the moment, I will focus on rewriting my object management when I change scene to don’t destroy Recast.

If you have a small use case that still OOM, I’ll do a test on my side too.
For now, the best test I think is to keep the plugin then create/destroy a navmesh multiple times.

Hello @Cedric,
I remade my object management to leave the first instance of Recast alive. Now I don’t have OOM anymore. So it’s a success.

Just for my personal understanding, I did the create/destroy test that you suggested. With memory profiling, I see that the items __cache__ (Recast.Crowd.__cache__,…) fills each time I create a new navmesh and they are don’t free when I destroy the new navmesh.
How the memory in Recast is managed?
When the __cache__ items are free or reused?
Do I need to do something to tell Recast to manage its memory (other than destroying the navmesh)?

No, the interface is simple and enough for that. If, for some reason, even with create/destroy there is still OOM, then it’s an issue on the C++ side.

I believe Recast keeps some pre-allocated buffers for faster allocations.

1 Like

Understood. I will stop to be paranoid with the Recast memory.
Thank you Cedric.

1 Like