Autodesk Navigation offers two different ways to handle the presence of dynamic and destructible obstacles in the World. Which approach you should use depends primarily on whether or not the obstacles are moving.

• Moving obstacles that have physical extents are taken into account during path following by the dynamic avoidance system.

  When a Bot uses the default Trajectory class to generate a velocity that leads it toward its current target point, and that Bot has avoidance enabled, the avoidance system finds all nearby moving obstacles that might potentially produce collisions with the Bot. Based on the nearby colliders and their velocities, the avoidance system attempts to find a safe velocity for its Bot that will avoid collisions. For more information on the path following system, see Path Finding and Path Following.

• Stationary obstacles, and non-physical objects, are integrated directly into the NavMesh, dynamically changing the NavData around them to reflect their presence.

  The dynamically modified NavMesh takes the place of the pre-generated NavMesh that you streamed into your game. Any queries that are run against the Database, including the path finding queries used by your Bots, automatically take the dynamically modified NavMesh into account instead of the pre-generated NavMesh.

There are three possible classes that you can use to represent your obstacles:

The TagVolume class represents a stationary physical obstacle or abstract zone whose extents are always integrated into the NavMesh.

Each TagVolume tags the area of the NavMesh it covers with a NavTag that you set up in the object initialization. This NavTag can be flagged as "exclusive," which marks the area as non-navigable—essentially punching a hole in the NavMesh. Alternatively, it can tag the area with a custom array of integer data values, which you can retrieve and handle during path finding, path following and queries. For details on the NavTag system, see Tagging with Custom Data.

For example, the TagVolume on the right has been flagged as exclusive. The one on the left has tagged the NavMesh with custom data; it is still walkable by default, but you can detect and respond to the NavTag during your path following.

Use this class directly to represent:

• Obstacles or zones without blocking physical volumes, such as minefields, flooded areas, zones with different types of terrain, etc.
• Physical obstacles that are relatively stationary, and whose extents and position are not expected to change, such as trees, lampposts, large furniture or crates, etc.

See Setting up TagVolumes.

The CylinderObstacle class represents a moveable physical object whose dimensions are best expressed as a single cylinder.

By default, these objects are taken into account only by the dynamic avoidance system. However, when they become stationary, you can easily request them to integrate themselves into the NavMesh instead, which they do by transparently spawning an internal TagVolume.

For example, the orange cylinders on the left are moving, and taken into account only by dynamic avoidance. The other cylinders are stationary and integrated into the NavMesh: the cylinder on the grey area has a NavTag that is set as exclusive, and the cylinder on the green area has a NavTag with a custom data value.

Use this class to represent:

• Player-controlled characters.
• Cylindrical objects such as barrels or poles, provided that their axes remain close to vertical.

See Setting up CylinderObstacles.

The BoxObstacle class represents any moveable or free-rotating physical object with fixed extents and a box-shaped volume.

By default, these objects are taken into account only by the dynamic avoidance system. However, when they become stationary, you can easily request them to integrate themselves into the NavMesh instead, which they do by transparently spawning an internal TagVolume.

For example, the orange boxes on the left are moving and rotating freely, and thus taken into account only by dynamic avoidance. The other boxes are stationary and integrated into the NavMesh: the box on the grey area has a NavTag that is set as exclusive, and the box on the brown area has a NavTag with a custom data value.

Use this class to represent:

• Moving vehicles.
• Crates or furniture that can be moved, doors, rubble after an explosion, etc.

See Setting up BoxObstacles.

Integrating TagVolumes into the NavMesh can be computationally intensive. The process is automatically time-sliced in order to avoid CPU peaks, but there is no guarantee that a new TagVolume will be integrated into the NavMesh immediately, or even within a given number of frames.

For best performance:

• Where possible, avoid loading or unloading new NavData while the dynamic NavMesh is being updated. Because the dynamic NavMesh relies on the static NavData, updates to the static NavMesh in the Database take priority over updates to the dynamic NavMesh. If the dynamic NavMesh is in the process of being updated, and you add or remove static NavData in the Database, the update to the dynamic NavMesh is stopped until the Database has finished its update to the static NavData.
• Where possible, group together the creation and destruction of your TagVolumes into the same frame, so that you do not waste time re-computing the dynamic NavMesh for the same cells over and over.
• The merging and integration process operates on each cell of the NavMesh in turn. If you cannot group the creation and removal of all of your TagVolumes into the same frame, you may be able to reduce update time by grouping them by spatial location.