Class RecastGraph Extends NavmeshBase, IUpdatableGraph

float MaxTileConnectionEdgeDistance

Maximum (vertical) distance between the sides of two nodes for them to be connected across a tile edge.

When tiles are connected to each other, the nodes sometimes do not line up perfectly so some allowance must be made to allow tiles that do not match exactly to be connected with each other.

float NavmeshCuttingCharacterRadius

bool RecalculateNormals

Determines how normals are calculated.

Disable for spherical graphs or other complicated surfaces that allow the agents to e.g walk on walls or ceilings.

By default the normals of the mesh will be flipped so that they point as much as possible in the upwards direction. The normals are important when connecting adjacent nodes. Two adjacent nodes will only be connected if they are oriented the same way. This is particularly important if you have a navmesh on the walls or even on the ceiling of a room. Or if you are trying to make a spherical navmesh. If you do one of those things then you should set disable this setting and make sure the normals in your source mesh are properly set.

If you for example take a look at the image below. In the upper case then the nodes on the bottom half of the mesh haven't been connected with the nodes on the upper half because the normals on the lower half will have been modified to point inwards (as that is the direction that makes them face upwards the most) while the normals on the upper half point outwards. This causes the nodes to not connect properly along the seam. When this option is set to false instead the nodes are connected properly as in the original mesh all normals point outwards.

The default value of this field is true to reduce the risk for errors in the common case. If a mesh is supplied that has all normals pointing downwards and this option is false, then some methods like PointOnNavmesh will not work correctly as they assume that the normals point upwards. For a more complicated surface like a spherical graph those methods make no sense anyway as there is no clear definition of what it means to be "inside" a triangle when there is no clear up direction.

float TileWorldSizeX

Size of a tile in world units along the X axis.

float TileWorldSizeZ

Size of a tile in world units along the Z axis.

BackgroundTraversability backgroundTraversability = BackgroundTraversability.Walkable

Whether the base of the graph should default to being walkable or unwalkable.

This is only used in 2D mode. In 3D mode, this setting has no effect.

For 2D games, it can be very useful to set the background to be walkable by default, and then constrain walkability using colliders.

If you don't want to use a walkable background, you can instead create colliders and attach a RecastNavmeshModifier with Surface Type set to Walkable Surface. These will then create walkable regions.

Bounds bounds

World bounding box for the graph.

This always contains the whole graph.

float cellSize = 0.25F

Voxel sample size (x,z).

When generating a recast graph what happens is that the world is voxelized. You can think of this as constructing an approximation of the world out of lots of boxes. If you have played Minecraft it looks very similar (but with smaller boxes). The cell size is the width and depth of those boxes. The height of the boxes is usually much smaller and automatically calculated, however.

Lower values will yield higher quality navmeshes, however the graph will be slower to scan.

float characterRadius = 0.5F

Radius of the agent which will traverse the navmesh.

The navmesh will be eroded with this radius.

This value will be rounded up to the nearest multiple of cellSize.

CollectionSettings collectionSettings = new CollectionSettings()

Determines which objects are used to build the graph, when it is scanned.

Also contains some settings for how to convert objects into meshes. Spherical colliders, for example, need to be converted into a triangular mesh before they can be used in the graph.

float contourMaxError = 2F

Max distance from simplified edge to real edge.

This value is measured in voxels. So with the default value of 2 it means that the final navmesh contour may be at most 2 voxels (i.e 2 times cellSize) away from the border that was calculated when voxelizing the world. A higher value will yield a more simplified and cleaner navmesh while a lower value may capture more details. However a too low value will cause the individual voxels to be visible (see image below).

DimensionMode dimensionMode = DimensionMode.Dimension3D

Whether to use 3D or 2D mode.

int editorTileSize = 128

Size in voxels of a single tile.

This is the width of the tile.

A large tile size can be faster to initially scan (but beware of out of memory issues if you try with a too large tile size in a large world) smaller tile sizes are (much) faster to update.

Different tile sizes can affect the quality of paths. It is often good to split up huge open areas into several tiles for better quality paths, but too small tiles can also lead to effects looking like invisible obstacles. For more information about this take a look at Notes about navmesh graphs. Usually it is best to experiment and see what works best for your game.

When scanning a recast graphs individual tiles can be calculated in parallel which can make it much faster to scan large worlds. When you want to recalculate a part of a recast graph, this can only be done on a tile-by-tile basis which means that if you often try to update a region of the recast graph much smaller than the tile size, then you will be doing a lot of unnecessary calculations. However if you on the other hand update regions of the recast graph that are much larger than the tile size then it may be slower than necessary as there is some overhead in having lots of tiles instead of a few larger ones (not that much though).

Recommended values are between 64 and 256, but these are very soft limits. It is possible to use both larger and smaller values.

Vector3 forcedBoundsCenter

Center of the bounding box.

Scanning will only be done inside the bounding box

float maxEdgeLength = 20

Longer edges will be subdivided.

Reducing this value can sometimes improve path quality since similarly sized triangles yield better paths than really large and really triangles small next to each other. However it will also add a lot more nodes which will make pathfinding slower. For more information about this take a look at Notes about navmesh graphs.

float maxSlope = 30

Max slope in degrees the character can traverse.

List<(UnityEngine.Object, Mesh)> meshesUnreadableAtRuntime

Internal field used to warn users when the mesh includes meshes that are not readable at runtime.

float minRegionSize = 3

Minumum region size.

Small regions will be removed from the navmesh. Measured in voxels.

If a region is adjacent to a tile border, it will not be removed even though it is small since the adjacent tile might join it to form a larger region.

List<PerLayerModification> perLayerModifications = new List<PerLayerModification>()

List of rules that modify the graph based on the layer of the rasterized object.

By default, all layers are treated as walkable surfaces. But by adding rules to this list, one can for example make all surfaces with a specific layer get a specific pathfinding tag.

Each layer should be modified at most once in this list.

If an object has a RecastNavmeshModifier component attached, the settings on that component will override the settings in this list.

RelevantGraphSurfaceMode relevantGraphSurfaceMode = RelevantGraphSurfaceMode.DoNotRequire

Require every region to have a RelevantGraphSurface component inside it.

A RelevantGraphSurface component placed in the scene specifies that the navmesh region it is inside should be included in the navmesh.

If this is set to OnlyForCompletelyInsideTile a navmesh region is included in the navmesh if it has a RelevantGraphSurface inside it, or if it is adjacent to a tile border. This can leave some small regions which you didn't want to have included because they are adjacent to tile borders, but it removes the need to place a component in every single tile, which can be tedious (see below).

If this is set to RequireForAll a navmesh region is included only if it has a RelevantGraphSurface inside it. Note that even though the navmesh looks continous between tiles, the tiles are computed individually and therefore you need a RelevantGraphSurface component for each region and for each tile.

In the above image, the mode OnlyForCompletelyInsideTile was used. Tile borders are highlighted in black. Note that since all regions are adjacent to a tile border, this mode didn't remove anything in this case and would give the same result as DoNotRequire. The RelevantGraphSurface component is shown using the green gizmo in the top-right of the blue plane.

In the above image, the mode RequireForAll was used. No tiles were used. Note that the small region at the top of the orange cube is now gone, since it was not the in the same region as the relevant graph surface component. The result would have been identical with OnlyForCompletelyInsideTile since there are no tiles (or a single tile, depending on how you look at it).

The mode RequireForAll was used here. Since there is only a single RelevantGraphSurface component, only the region it was in, in the tile it is placed in, will be enabled. If there would have been several RelevantGraphSurface in other tiles, those regions could have been enabled as well.

Here another tile size was used along with the OnlyForCompletelyInsideTile. Note that the region on top of the orange cube is gone now since the region borders do not intersect that region (and there is no RelevantGraphSurface component inside it).

Vector3 rotation

Rotation of the graph in degrees.

bool scanEmptyGraph

If true, scanning the graph will yield a completely empty graph.

Useful if you want to replace the graph with a custom navmesh for example

int tileSizeX = 128

Size of a tile along the X axis in voxels.

This is the width of the tile.

A large tile size can be faster to initially scan (but beware of out of memory issues if you try with a too large tile size in a large world) smaller tile sizes are (much) faster to update.

Different tile sizes can affect the quality of paths. It is often good to split up huge open areas into several tiles for better quality paths, but too small tiles can also lead to effects looking like invisible obstacles. For more information about this take a look at Notes about navmesh graphs. Usually it is best to experiment and see what works best for your game.

When scanning a recast graphs individual tiles can be calculated in parallel which can make it much faster to scan large worlds. When you want to recalculate a part of a recast graph, this can only be done on a tile-by-tile basis which means that if you often try to update a region of the recast graph much smaller than the tile size, then you will be doing a lot of unnecessary calculations. However if you on the other hand update regions of the recast graph that are much larger than the tile size then it may be slower than necessary as there is some overhead in having lots of tiles instead of a few larger ones (not that much though).

Recommended values are between 64 and 256, but these are very soft limits. It is possible to use both larger and smaller values.

int tileSizeZ = 128

Size of a tile along the Z axis in voxels.

This is the width of the tile.

A large tile size can be faster to initially scan (but beware of out of memory issues if you try with a too large tile size in a large world) smaller tile sizes are (much) faster to update.

Different tile sizes can affect the quality of paths. It is often good to split up huge open areas into several tiles for better quality paths, but too small tiles can also lead to effects looking like invisible obstacles. For more information about this take a look at Notes about navmesh graphs. Usually it is best to experiment and see what works best for your game.

When scanning a recast graphs individual tiles can be calculated in parallel which can make it much faster to scan large worlds. When you want to recalculate a part of a recast graph, this can only be done on a tile-by-tile basis which means that if you often try to update a region of the recast graph much smaller than the tile size, then you will be doing a lot of unnecessary calculations. However if you on the other hand update regions of the recast graph that are much larger than the tile size then it may be slower than necessary as there is some overhead in having lots of tiles instead of a few larger ones (not that much though).

Recommended values are between 64 and 256, but these are very soft limits. It is possible to use both larger and smaller values.

bool useTiles = true

If true, divide the graph into tiles, otherwise use a single tile covering the whole graph.

Using tiles is useful for a number of things. But it also has some drawbacks.

• Using tiles allows you to update only a part of the graph at a time. When doing graph updates on a recast graph, it will always recalculate whole tiles (or the whole graph if there are no tiles). NavmeshCut components also work on a tile-by-tile basis.

• Using tiles allows you to use NavmeshPrefabs.

• Using tiles can break up very large triangles, which can improve path quality in some cases, and make the navmesh more closely follow the y-coordinates of the ground.

• Using tiles can make it much faster to generate the navmesh, because each tile can be calculated in parallel. But if the tiles are made too small, then the overhead of having many tiles can make it slower than having fewer tiles.

• Using small tiles can make the path quality worse in some cases, but setting the FunnelModifiers quality setting to high (or using RichAI.funnelSimplification) will mostly mitigate this.

float walkableClimb = 0.5F

Height the character can climb.

float walkableHeight = 2F

Character height.

BackgroundTraversability

Whether the base of the graph should default to being walkable or unwalkable.

DimensionMode

Whether to use 3D or 2D mode.

RelevantGraphSurfaceMode

System.Action<NavmeshTile[]> OnRecalculatedTiles

Called when tiles have been completely recalculated.

This is called after scanning the graph and after performing graph updates that completely recalculate tiles (not ones that simply modify e.g penalties). It is not called after NavmeshCut updates.

const int TileIndexMask = 0x7FFFF

const int TileIndexOffset = 12

const int VertexIndexMask = 0xFFF

AstarPath active

Reference to the AstarPath object in the scene.

Bounds bounds

World bounding box for the graph.

This always contains the whole graph.

It is ok for a graph type to return an infinitely large bounding box, but this may make some operations less efficient. The point graph will always return an infinitely large bounding box.

bool drawGizmos = true

Enable to draw gizmos in the Unity scene view.

In the inspector this value corresponds to the state of the 'eye' icon in the top left corner of every graph inspector.

bool enableNavmeshCutting = true

Should navmesh cuts affect this graph.

Vector3 forcedBoundsSize = new Vector3(100, 40, 100)

Size of the bounding box.

uint graphIndex

Index of the graph, used for identification purposes.

Guid guid

Used as an ID of the graph, considered to be unique.

bool infoScreenOpen

Used in the editor to check if the info screen is open.

Should be inside UNITY_EDITOR only #ifs but just in case anyone tries to serialize a NavGraph instance using Unity, I have left it like this as it would otherwise cause a crash when building. Version 3.0.8.1 was released because of this bug only

uint initialPenalty

Default penalty to apply to all nodes.

bool isScanned

True if the graph has been scanned and contains nodes.

Graphs are typically scanned when the game starts, but they can also be scanned manually.

If a graph has not been scanned, it does not contain any nodes and it not possible to use it for pathfinding.

string name

Name of the graph.

Can be set in the unity editor

NavmeshUpdates.NavmeshUpdateSettings navmeshUpdateData

Handles navmesh cutting.

bool open

Is the graph open in the editor.

bool persistent

True if the graph will be included when serializing graph data.

If false, the graph will be ignored when saving graph data.

Most graphs are persistent, but the LinkGraph is not persistent because links are always re-created from components at runtime.

bool showInInspector

True if the graph should be visible in the editor.

False is used for some internal graph types that users don't have to worry about.

bool showMeshOutline = true

Show an outline of the polygons in the Unity Editor.

bool showMeshSurface = true

Show the surface of the navmesh.

bool showNodeConnections

Show the connections between the polygons in the Unity Editor.

int tileXCount

Number of tiles along the X-axis.

int tileZCount

Number of tiles along the Z-axis.

GraphTransform transform = GraphTransform.identityTransform

Determines how the graph transforms graph space to world space.

int CharacterRadiusInVoxels

Convert character radius to a number of voxels.

int TileBorderSizeInVoxels

Number of extra voxels on each side of a tile to ensure accurate navmeshes near the tile border.

The width of a tile is expanded by 2 times this value (1x to the left and 1x to the right)

float TileBorderSizeInWorldUnits

bool exists

True if the graph exists, false if it has been destroyed.

bool hasExtendedInX = false

bool hasExtendedInZ = false

DisposeArena pendingGraphUpdateArena = new DisposeArena()

NavmeshTile[] tiles

All tiles.

float colliderRasterizeDetail

Controls detail on rasterization of sphere and capsule colliders.

The colliders will be approximated with polygons so that the max distance to the theoretical surface is less than 1/(this number of voxels).

A higher value does not necessarily increase quality of the mesh, but a lower value will often speed it up.

You should try to keep this value as low as possible without affecting the mesh quality since that will yield the fastest scan times.

The default value is 1, which corresponds to a maximum error of 1 voxel. In most cases, increasing this to a value higher than 2 (corresponding to a maximum error of 0.5 voxels) is not useful.

LayerMask mask

Layer mask which filters which objects to include.

bool rasterizeColliders

Use colliders to calculate the navmesh.

Depending on the dimensionMode, either 3D or 2D colliders will be rasterized.

Sphere/Capsule/Circle colliders will be approximated using polygons, with the precision specified in colliderRasterizeDetail.

bool rasterizeMeshes

Use scene meshes to calculate the navmesh.

This can get you higher precision than colliders, since colliders are typically very simplified versions of the mesh. However, it is often slower to scan, and graph updates can be particularly slow.

The reason that graph updates are slower is that there's no efficient way to find all meshes that intersect a given tile, so the graph has to iterate over all meshes in the scene just to find the ones relevant for the tiles that you want to update. Colliders, on the other hand, can be efficiently queried using the physics system.

You can disable this and attach a RecastNavmeshModifier component (with dynamic=false) to all meshes that you want to be included in the navmesh instead. That way they will be able to be efficiently queried for, without having to iterate through all meshes in the scene.

In 2D mode, this setting has no effect.

bool rasterizeTerrain

Use terrains to calculate the navmesh.

In 2D mode, this setting has no effect.

bool rasterizeTrees

Rasterize tree colliders on terrains.

If the tree prefab has a collider, that collider will be rasterized. Otherwise a simple box collider will be used and the script will try to adjust it to the tree's scale, it might not do a very good job though so an attached collider is preferable.

In 2D mode, this setting has no effect.

List<string> tagMask

Objects tagged with any of these tags will be rasterized.

Note that this extends the layer mask, so if you only want to use tags, set mask to 'Nothing'.

int terrainSampleSize

Controls how large the sample size for the terrain is.

A higher value is faster to scan but less accurate.

The heightmap resolution is effectively divided by this value, before the terrain is rasterized.