Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Building navmesh #57

Closed
YuryKonvpalto opened this issue Jan 23, 2022 · 2 comments
Closed

Building navmesh #57

YuryKonvpalto opened this issue Jan 23, 2022 · 2 comments

Comments

@YuryKonvpalto
Copy link

YuryKonvpalto commented Jan 23, 2022

After bunch of tests I figured out that NavMeshLoader() considers a tris (triangles) of the mesh as a separate regions only if the mesh (and all the tris of it) is twisted - e.g. tris have different y-coord and are not belonging to one plane.
Otherwise it either builds a large regions from many tris on plane or just hangs the browser (if there are > than say 100 of tris).

E.g. I add a plane in Blender => Triangulate faces (quad becomes separated in two tris) => Subdivide it 4-times and when doing that have to set a tiny amount of "Fractal" (in order the surface of the plane would bend-twist a little bit). This way NavMeshLoader() loads the mesh and considers each tri as a separate region.
When the the "Fractal" option in "Subdivide" window is set to 0, the surface stays flat. This way NavMeshLoader() either could not load the mesh (when subdivided in 10) or builds large regions.

The question is - is it a correct behavior or I miss here smthg?

navmeshBlender

@Mugen87
Copy link
Owner

Mugen87 commented Jan 24, 2022

Sorry, I don't fully understand your issue.

Triangles are merged if it's possible to build convex regions. As the name implies convex regions have to be convex and coplanar.

When loading a nav mesh via NavMeshLoader.load(), you can use the options parameter to disable this processing. Just set mergeConvexRegions to false.

loader.load( path, { mergeConvexRegions: false } );

@YuryKonvpalto
Copy link
Author

Oh, thanks, that really did the job! It has not been mentioned in Yuka-Docs though.

Short question: each game-cell on the plane (each cell = tri ) has its own cost representing specific type of terrain (marsh, forest, hill etc.). So that e.g. NavEdge between flat terrain to hill has cost higher than node between two flat terrains.
Different types of terrain I gonna to mark in Blender with vertexpaint; different vertexcolor (red,green etc.) would correspond with specific cost for NavEdge. Then I iterate through all painted vertices of the plane to find matches with HalfEdges (vertices) of the navmesh-regions and apply costs to all NavEdges of the region if match is found.
Do I look in right direction or there could be other more simplified options?

@Mugen87 Mugen87 closed this as completed Mar 6, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants