Navmesh memory usage

Questions
, ,
1

Hi everyone!

I’m trying to run null engine on some memory constrained environment (web server), and I’ve been looking on potential optimizations for it. My max ram atm is 1024mb, and I’m hitting around 700mb when there is not much happening on the server.

I’m curious on how memory intense the recast is, and if there is any way to reduce the memory footprint. I have the following lines of code and they seem to basically take up 200-300mb of the memory. I understand I create the nav plugin two times, this is needed to actually have proper larger navmesh agents available in the game (since I think this is the only way to make the navmesh padding bigger so the big navmesh agents don’t clip through walls…)

    //@ts-ignore
    const recast = await new Recast()
    this.navigationPlugin = new RecastJSPlugin(recast)
    //@ts-ignore
    const recastLarge = await new Recast()
    this.navigationPluginLarge = new RecastJSPlugin(recastLarge)

Now, the new Recast part kind of interests me. I don’t see any docs on what this is actually importing and are we actually using the wasm Recast or just some js port of it? Could this save memory if we just force the wasm one and is it even possible?

Ping @Cedric the king of Navmesh content :slight_smile:

Thanks in advance of all the help you can give me! :heart:

Edit: For further information; I’m using Bun, not Node, to run the null engine. Everything works fine on it :slight_smile: Also the Havok physics work well and do not reserve almost any memory…

1 Like
2

This is using a wasm verstion of recast bundled within the js but I guess the footprint would be similar relying on an external wasm.

I ll let @Cedric comment after the holidays but I am not sure this is where you ll find back some memory.

1 Like
3

wasm is embedded in the js and should not be a problem.
I think memory is pre allocated and it should be possible to make it available dynamically instead.
Do you have a sample project I can use to test a fix?

1 Like
5

I can create a simple repo later on, my current project is pretty large atm :smiley: Also, what do you mean by “wasm is embedded in the js”, do you mean that we use the actual wasm file still with minimum js?

6

a build with emscripten can either produce a .js + .wasm or a .js that contains the wasm as a base64 string. Both should have same footprint at the end.

7

I’m a bit sceptical on the same footprint especially using Bun, at least if we have to interpret the base64 string when we could use the raw wasm file :thinking: Of course I can be wrong… Is there any way to run/use the raw wasm?

8

I guess it’s possible to use the wasm directly as it’s what the glue .js does. In base64 or binary, the wasm will be convert in memory to a useable form by the browser. At the end, I don’t think it will make a memory or performance difference.

1 Like
9

Hi @Panuchka

I’ve open a PR with a new build of Recastjs Update Recast.js by CedricGuillemet · Pull Request #16072 · BabylonJS/Babylon.js · GitHub
It only use dynamic memory allocation so you should see a difference. Please test it and I’ll release a new NPM package if it works for you.

2 Likes
10

Sweet I’ll test it asap!

1 Like
11

Tested on server, and it looks like it uses around 200mb less memory now! Huge! :smiley:
Has some issues testing it in the client (browser) since there was no es6 build? So I used the old recast-detour one.

Are there any downsides on the dynamic memory allocation?

Here is a picture of happy navmesh users :slight_smile:
navmeshtest3

2 Likes
12

The picture looks great !!!

1 Like
13

for many allocation/deallocation, this would be an issue but recast uses pools so you should so no difference in perf.

1 Like