I am currently working on a project featuring a large square map which is a grid made of 5x5 cells. The goal is to select one of the cells to make an avatar spawn in it and make it able to navigate inside the cell with a navmesh.
For performance reasons, I’d like to keep separate navmeshes (one for each cell) and only load the one corresponding to the cell once it has been chosen (I made all navmeshes in blender and baked them with the great babylon.js NavMesh Editor).
The issue I am facing is that by default all navmeshes load at coordinates (0,0) of my grid, so they do not correspond with the cell’s location in the scene.
The only way I found to make them load “in” the cell, is to include the needed offset directly from the modelling step in Blender. Although it is working, I find it kind of unconvenient.
Is there another simpler solution that I missed to “move” the navmesh once it has been loaded ?
I quickly checked and did not see anything related to an offset for navmesh.
It looks possible to provide an origin when initializing tiles but I’ve never tested it.
How big is each cell navigation mesh data? Maybe you don’t need to split?
If cell are independent, you can do a conversion of space between rendering and navigation.
Navmesh stays at 0,0,0 but you add/remove offset when converting from a path to the corresponding rendering world position.
Thank you for having a look at it.
Each cell is 40x40 meters, the whole grid is supposed to represent a small city. The number of cells may increase in further versions, that is why I thought splitting would be nice for performance.
Converting coordinates is an interesting idea, I will probably go for that if there is nothing more “built-in”.
Thank you for the suggestion !
I put together a quick solution, but I haven’t had time to test it thoroughly, so I can’t guarantee that it will work without any flaws. Feel free to try it out and let me know if you run into any issues. I’d love to refine it, but I have a lot on my plate at work right now.
The offset will be applied to the exported data only, so you won’t see any changes on the screen:
Thank you ! I will have a look at it and tell you if I get any problems.
I also thought about another approach. Would it be possible to provide the x,y,z offset at import time ? (for example in the buildFromNavmeshData(...) function, along with the navmesh data itself.
It would allow to store all the offsets in a config file, apply them at runtime, and easily modify them if needed. This would also make navmeshes reusable in different contexts.
I have done some testing and it seems that the offset is not taken into account.
I get the same results with an offset (I tried different x,y,z combinations) and without it (left at 0,0,0). The result is the same as in the other version of the navmesh editor, navmesh coordinates are relative to the origin of the scene, with no offset.
I know it requires some time to fix this, so let me know if can I help you with some other tests.
In any case, thank you for your time !
