Difference between revisions of "NAVCUT"

From the CreationKit Wiki
Jump to navigation Jump to search
imported>DavidJCobb
(Created page with an explanation of NAVCUT, as well as known limitations and details based on testing)
 
imported>DavidJCobb
m (→‎Limitations of NAVCUT: NIFs are fine, I'm pretty sure)
Line 19: Line 19:
== Limitations of NAVCUT ==
== Limitations of NAVCUT ==
;Characters aren't conscious of their own size when walking near NAVCUT volumes.
;Characters aren't conscious of their own size when walking near NAVCUT volumes.
:As far as NAVCUT is concerned, characters are zero-size: if you try to cut an area in two using NAVCUT and you leave so much as a one-inch gap of uncovered navmesh connecting the two halves, then characters that want to path to the other side will walk along that gap. Characters will also walk ''right up to'' a NAVCUT volume, stopping with their origin-positions right along its edge.
:As far as NAVCUT volumes are concerned, characters are zero-size: if you try to cut an area in two using NAVCUT and you leave so much as a one-inch gap of uncovered navmesh connecting the two halves, then characters that want to path to the other side will walk along that gap. Characters will also walk ''right up to'' a NAVCUT volume, stopping with their origin-positions right along its edge.
:If you're using NAVCUT to ensure that characters smoothly walk around some object, then the solution here is to expand the NAVCUT box laterally by half the thickness of an actor.
:If you're using NAVCUT volumes to ensure that characters smoothly walk around some object, then the solution here is to expand the NAVCUT boxes laterally by half the thickness of an actor. NAVCUT NIFs don't appear to have this problem, and shouldn't need to be expanded.


;NAVCUT only works while the player is in the area.
;NAVCUT only works while the player is in the area.

Revision as of 19:11, 30 September 2017

A navigation mesh is used to tell NPCs where they can walk. NAVCUT volumes are used to selectively "turn off" parts of the navmesh.

Overview

Imagine that you have a pet robot.

DwemerSpider.png

Your pet robot has very poor vision; everything is a confusing blur to it, and it keeps bumping into walls whenever it tries to walk around your house. However, it can see color just fine. You decide to solve the problem by painting the floors of your house red, and teaching the robot to only walk where it sees red. In a video game, we call that red paint a "navigation mesh" or "navmesh," and it covers anywhere that a character can safely walk.

Now imagine that there are some rooms that you don't always want your pet robot to enter. It needs to be able to find its way into those rooms sometimes, but there are occasions where you want it to stay out. You might solve the problem by laying a blue blanket over the entrances to the rooms, so that the robot can't see a red path. In Skyrim, we call these blue blankets "NAVCUT primitives," because they are simple shapes ("primitives," like cubes and spheres) that "cut" a navmesh into pieces to block paths. We can "enable" a NAVCUT primitive to block access to a location, and then "disable" it to allow access again, and this is useful for things like retractable bridges and destructible walkways.

Ways to apply NAVCUT

Primitives
Collision primitives can be placed in the Creation Kit and given the L_NAVCUT layer. They will then act as NAVCUT volumes, blocking pathing whenever they are enabled.
NIF data
It is possible to add collision data to a 3D model and flag it as NAVCUT. In a bhkRigidBody block, change the "Havok Col Filter" and "Havok Col Filter Copy" data so that the collision layer used is 49. (As of this writing, NifSkope doesn't understand that the value "49" means "NAVCUT," but it will let you enter and save the value.) Note that NAVCUT collision still is collision: if you want the object to remain immovable and behave stably, you will also need to set the collision's Mass to zero.

Limitations of NAVCUT

Characters aren't conscious of their own size when walking near NAVCUT volumes.
As far as NAVCUT volumes are concerned, characters are zero-size: if you try to cut an area in two using NAVCUT and you leave so much as a one-inch gap of uncovered navmesh connecting the two halves, then characters that want to path to the other side will walk along that gap. Characters will also walk right up to a NAVCUT volume, stopping with their origin-positions right along its edge.
If you're using NAVCUT volumes to ensure that characters smoothly walk around some object, then the solution here is to expand the NAVCUT boxes laterally by half the thickness of an actor. NAVCUT NIFs don't appear to have this problem, and shouldn't need to be expanded.
NAVCUT only works while the player is in the area.
If a character's AI package is telling that character to travel to a given area (such as a piece of furniture), NAVCUT will only stop them from walking there while the player is in the current cell. When the player leaves the cell, the game stops simulating characters' positions in real-time -- which also means that the game stops processing NAVCUT. When the player re-enters the cell, the game "makes up for lost time" by teleporting the character to wherever their AI package says they should be, regardless of what NAVCUT boxes are in the cell.
NAVCUT boxes will only affect a character's pathing if they are present and enabled when the character has started pathing.
If a NAVCUT box is enabled after a character has already started walking to a location, then they may not notice the change: they may walk right through the NAVCUT volume. Objects with NAVCUT data in their meshes seem to behave differently: followers will stop and restart pathing every time such objects are moved (e.g. by a script)

Implementation details

  • NAVCUT volumes don't need to cover entire triangles. They do literally cut the navmesh.
  • Despite some of the issues listed in the "Limitations" section above, a NAVCUT box doesn't need to be thicker than a character model if the box completely cuts a navmesh into two pieces.
  • NAVCUT volumes have collision generated at run-time. The engine only does this properly if they use the hardcoded CollisionMarker base form. Collision primitives placed in the Creation Kit will always be CollisionMarkers.