Navmesh cuts on navmesh based on a source mesh


#1

I’m using a nav mesh graph using a actual mesh as the source mesh.
Is there a way to cut the navmesh in the editor? I have several objects I would want to cut out, and it doesn’t have to be on runtime. The NavmeshCut script doesn’t seem to update the graph when I rescan after adding it.
I’ve look at this thread here NavMesh cutting during bake but the RecastMeshObj doesn’t seem to do it either.
Any suggestions?


#2

Is the NavmeshCut component not meant for non-realtime usage?

Thank you.


#3

Hmm, wondering if I can make a navigation mesh with a custom mesh, that’s defined as NOT walkable?
@aron_granberg is this possible?
Currently the setup is my planet with a mesh navmesh of the whole planet surface. This works great, however we have loads of objects and prefabs placed on the planet. Now, it is possible for us to export all these as a single object, but we can’t delete intersections from the planet surface that way. So is it possible to define a navmesh based on a source mesh, that’s not walkable?


#4

Hi

NavmeshCutting is not intended for use in the editor, no. However applying them during runtime shouldn’t be a problem. They use almost no CPU power when they are not moving. Note however that navmesh cutting does not work for spherical navmeshes (they need some well defined cutting direction).

That’s not possible really. If you are doing this in an external modelling program you might be able to use a difference operation (see for example https://docs.blender.org/manual/en/dev/modeling/modifiers/generate/booleans.html) to remove all your obstacles from a starting sphere mesh representing the planet.


#5

Thanks a lot for your answer. We’re currently experimenting with cutting out the objects on the surface mesh. If only you could define a mesh that’s non walkable haha, that might fix it all.
Anyway, thanks again for your patience and answers.


#6

Yeah, the problem with defining a mesh that is not walkable is that there is no way to know what should be between those regions of unwalkable parts.


#7

No, but that’s where another navmesh would come in.
Say I export all the stuff placed on my planet as one object, and then use that as the “non walkable” navmesh, while I’m still using the mesh of the planet’s surface as the walkable navmesh.


#8

Ah, so you don’t really mean a non walkable navmesh, but a volume that you cut out from an existing navmesh?
If so, the difference operation in many modelling applications sounds perfect for you.


#9

Yeah, gonna give boolean operations another shot, it was done horribly the first few tests we did haha!

  • Just to clarify, I see that I can make multiple navmeshes. And therefor I wondered if it would fix it to have two nav meshes based from a source mesh. One of the planet surface, and one of all the objects on the planet. The second navmesh should then be defined as non walkable, haha, doesn’t matter though, it’s not possible or supported pt! :slight_smile:

Thank you, I’ll take a look at the different operations in Blender.


#10

For grid based data that would make sense, but for navmesh based data you really need to have something that cuts away the existing navmesh data where it shouldn’t be possible to walk.


#11

Yeah it would introduce a problem with overlapping navmeshes, and then some further functionality to differ between the two. Ah well.