Navigation plugin computeSmooth

Questions
1

Hey guys!

I wrote a drop in replacement navigation plugin which implements INavigationEnginePlugin and uses GitHub - isaac-mason/recast-navigation-js: JavaScript navigation mesh construction, path-finding, and spatial reasoning toolkit. WebAssembly port of Recast Navigation. which ships as ECMAScript modules and is compatible with Node.js and browser environments and is actually actively maintained.

The only thing I couldn’t look up what the computePathSmooth(start: Vector3, end: Vector3): Vector3[] function does?

@Cedric could you lend me a helping hand on this, please?

The plugin will be available as open source or we could even replace the problematic current recast.js stuff with this one.

3 Likes
2

I’ve found some context here : NavMesh: Paths don't follow NavMesh surface - #10 by Cedric

and related PR : expose seed and computepath smooth by CedricGuillemet · Pull Request #265 · BabylonJS/Extensions · GitHub

IIRC, default path computation is straight and does not respect navmesh geometry. The change improves path computation with more respectful to corridors and heights.

I’m all in with recast.js replacement as long as features available and documented are present :slight_smile:

2 Likes
3

Since it implements INavigationEnginePlugin nothing changes from the user’s perspective.

Thanks for the links!

1 Like
4

I found this link and only this one earlier :slight_smile: Unfortunately there is no more information on computeSmooth on the forum.

I went trough the code at expose seed and computepath smooth by CedricGuillemet · Pull Request #265 · BabylonJS/Extensions · GitHub and I assume it is the same as computePath but the resulting path contains more points. Is it correct?

5

yes, path should look like the trail made by an agent and not the jaggy lines with computepath.

1 Like
6

recast-js on the left (currently used in babylonjs), recast-navigation-js on the right (the new one):

image
image2086×1052 83.1 KB

There is a small difference in the navmesh generated by the two implementions. I think, the new one is doing the right thing because the sphere is placed at the world origin and it is symmetric so the navmesh should be symmetric as well.

Any inputs on this? @Cedric

Thanks a lot!

7

Are the options exactly the same (cell size, cell height,… ?) with same mesh and world sizes?

8

Everything is the same.

9

that’s interesting ! :slight_smile: maybe a missing triangle when transfering from c++ to JS? does the same happen with different setup?

10

I believe there is an extrta triangle and not a missing one, because if the whole scene/all the meshes are symmetric it has to generate a symmetric nav mesh. So the right one is correct.

Maybe some precision differences?