I have some questions about Navcuts seeing I really can't find the answers to them after a lot of searching:

1. When should they be used and when is it best to navmesh around the objects instead?


2. Are there any situations where they just will not work?


3. What objects need navcuts and which do not? I'm particularly interested in flora and trees in exterior spaces, but a general answer for all objects will work too.


4. Can these boxes be of any size and still work?

Thanks for your time!

whereever a collision primitive with the "navcut" collision layer selected in it's primitve tab covers a navmesh, this is treated as inexistent.

it's the same as if there was a collision-box-shaped hole in it.

therefore, they're apparently needed wherever you want NO navmesh,

like, a default application, if you put a 2001 monolith in some exterior cell and don't want folks to bump into it,

you can acchieve this by just covering the area it takes with a navcut without needing to make any changes to the actual navcut at all

(so it won't ever cause any compatibility issues with other mods editing the same navmesh, hence it's almost always the preferable option where applicable)

this will always work, as long as the primitive is enabled.

if you disable it, it'll stop doing it's thing instantly -> the navmesh will be back to valid and npc's will walk there again

no objects "need" navcuts.

you'll add a navcut to an object to prevent npc's from bumping into it (see above), that's all

...some base object types come with a "obstacle" option btw: this does just the same, using that object's collision to cut the navmesh (without needing an extra primitive, except if you want to cut a bigger hole than the precise object collision's size is)

you'll never need navcuts for flora, since npc's walk right through them anyway (except if you don't want them to do just that of course).

and yes, these boxes can be any size. and they can also be spheres btw.

...covered them all or forgot one?

The typical use for NAVCUT boxes is when you need the navmesh to conditionally allow an NPC across. For example, if you have a bridge that can be raised or lowered with a lever, you'd cover the bridge (in its lowered state) with navmesh, and then place a NAVCUT box on it. When the bridge is raised, you'll want to enable the NAVCUT; disable the NAVCUT when the bridge is lowered. Thus, NPCs will path across the bridge if it's walkable, and avoid it otherwise.

There are also variations on that pattern. I think Hearthfire uses disabled NAVCUT boxes where your decorations would go, and enables them when those decorations are built.

As s7o says, you can also use NAVCUT boxes to make changes to a vanilla/DLC cell's pathing without actually editing the navmesh.

Thanks for the responses. That does answer a few things. On the subject of the "Obstacle" tag on statics, https://forums.nexusmods.com/index.php?/topic/3903410-spawnable-navcut-cut-that-navmesh-realtime-in-game-on-the-fly/ would suggest they don't or don't always work. Thoughts?

The majority use for the L_NAVCUT boxes is variability. If an object is enabled, and the collision box with it, at some times, but not a others, then the block only exists when the object isn't there.

Used extensively in Hearthfires, as you're building new items on to of the nav-mesh all the time, but it's also used with things like drawbridges, where a blocking box is enabled when the bridge is up.