NavMesh isn't ignoring non-static stuff

I have things like ceilings and trees in my game set to non-static, so they shouldn't bake into the navmesh but they do for some reason. Help?

 

Me too. Even I set rigidbody box objects as NonWalkable, and didn't set static at all, they are baked with some NavMesh on it and around it.
This breaks all meanings of this attribute.

 

Same here, also Non-Static MeshRenderers block passages they didn't when using the original Nav-Mesh workflow. This makes the high-level package unusable in our current project (Doors which just swing open when a character gets near them now cut the nav-mesh).
As a workaround if you have a small project with not that many Layers, you should be able to exclude your trees etc. via the LayerMask from baking, but I guess you have to give at least the trees a nav-mesh obstacle so your agents can't run through them.

Since we are short on Layers due to Lighting and Physics stuff we sadly can't use that approach >.>

Have you reported it as a bug already?

 

When using the NavMesh Components the workflow is different than the built-in baking system. Which are you using?

When using the Navigation Panel to bake the navmesh, it will consider your Navigation Static objects.
When using the NavMeshSurface component it uses the configuration of the NavMeshSurface to determine which objects should be considered. You can check out this section of AI Series Part 1 that explains how the NavMeshSurface works.

 

Sure it's different but it can only be a bug to only be able to exclude gameObjects from the baking process via Layers instead of also using the gameObjects static-navigation flag. To push even more stuff you need to differ between to the layers where you only got 32 minus built-in layers is a big no-go and misuse of the physics-layers.

Also it makes the transition from the old workflow to the new one in existing projects horrible, when you need to set the layer of all previously non-navigation-static objects to a layer which you can exclude from the layer-mask. Sure you could automate that for simple setups, but what if your objects you want to exclude already exist on a layer for physics-tests and only some of them should be excluded from the navigation baking? You need an extra layer for any previously existing physics layer with gameobjects that can be both static and non static, need to assign the correct layer to any object and don't forget the prefabs, and then you got to adjust the collision-matrix etc.

Also it's not that the new components do something very differently from before regarding the bake process, the only difference is the old bake-process did discard gameObjects that were not marked navigation-static, while the new Prebake-Step "CollectSources()" inside the Surface does totally ignore that flag, why is there no "Exclude NonNavigationStatic" bool to do that in the component-settings, to at least be able to bake an nearly identical nav-mesh to the system, so you don't have re-setup a whole scene of gameObjects with layers etc?

Hell if they would've been mindfull enough to make that CollectSources-function protected instead of private I would override the Build-Function and throw away the "sources" which are non-navigation-static myself, but no, they made the collection of sources private so you can't call it yourself and manipulate the sources-list. Also why are there serialized fields for settings in the component which are not exposed via the custom-inspector, not every dev needs to have a gatekeeping in terms of handholding to make it easy to use, we need to be able to extend those components to do what we want them to do.
Makes you really want to ditch all those prebuilt-stuff which throws more obstacles in your way than it solves.

 

If you'd like to write your own baker in place of the NavMeshSurface, you can use the NavMeshBuilder API, specifically for the concerns you've highlighted, the NavMeshBuilder.CollectSources and from there you can iterate over the output results and do whatever kind of filtering you'd like, including discarding ones that are not marked as static. While that's not an "out of the box" solution from the NavMeshSurface component, it is something you can achieve still.

I hope that helps resolve the issues you're facing.

 

Little update, when using the new component-wise workflow you can also add NavMeshModifier and tick the Exclude-From-Build Checkbox this does practically the same thing as making a gameObject non-navigation-static in the old workflow as far as I can tell yet.

Since it's very tedious to do so for a Scene with a few thousand gameObjects you can also do so via an editor-script, just filter the objects for MeshRenderers (if you bake for those), add the modifier to each and set the exclusion to true if the gameObject is non-navigation-static you can grab that flag with GameObjectUtility-class.

Updating the object to have the same area set as with the old workflow mentioned by eurobax, you can override that via the same component too. However you get a brick thrown in your way if you also want to assign which agents are affected by the modifier from script. Since that list is private and there is only a method to check if a agent-type is affected. Only way to do this is to use reflection on it.