/// Automatically generates navmesh graphs based on world geometry.
///
/// [Open online documentation to see images]
///
/// The recast graph is based on Recast (http://code.google.com/p/recastnavigation/).
/// I have translated a good portion of it to C# to run it natively in Unity.
///
/// [Open online documentation to see images]
///
/// \section howitworks How a recast graph works
/// 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).
/// [Open online documentation to see images]
///
/// The Recast process is described as follows:
/// - The voxel mold is build from the input triangle mesh by rasterizing the triangles into a multi-layer heightfield.
/// Some simple filters are then applied to the mold to prune out locations where the character would not be able to move.
/// - The walkable areas described by the mold are divided into simple overlayed 2D regions.
/// The resulting regions have only one non-overlapping contour, which simplifies the final step of the process tremendously.
/// - The navigation polygons are peeled off from the regions by first tracing the boundaries and then simplifying them.
/// The resulting polygons are finally converted to triangles which makes them perfect for pathfinding and spatial reasoning about the level.
///
/// The recast generation process usually works directly on the visiable geometry in the world. This is usually a good thing, because world geometry is usually more detailed than the colliders.
/// You can, however, specify that colliders should be rasterized instead. If you have very detailed world geometry, this can speed up scanning and updating the graph.
///
/// \section export Exporting for manual editing
/// In the editor there is a button for exporting the generated graph to a .obj file.
/// Usually the generation process is good enough for the game directly, but in some cases you might want to edit some minor details.
/// So you can export the graph to a .obj file, open it in your favourite 3D application, edit it, and export it to a mesh which Unity can import.
/// You can then use that mesh in a navmesh graph.
///
/// Since many 3D modelling programs use different axis systems (unity uses X=right, Y=up, Z=forward), it can be a bit tricky to get the rotation and scaling right.
/// For blender for example, what you have to do is to first import the mesh using the .obj importer. Don't change anything related to axes in the settings.
/// Then select the mesh, open the transform tab (usually the thin toolbar to the right of the 3D view) and set Scale -> Z to -1.
/// If you transform it using the S (scale) hotkey, it seems to set both Z and Y to -1 for some reason.
/// Then make the edits you need and export it as an .obj file to somewhere in the Unity project.
/// But this time, edit the setting named "Forward" to "Z forward" (not -Z as it is per default).
/// Radius of the agent which will traverse the navmesh.
/// The navmesh will be eroded with this radius.
/// [Open online documentation to see images]
/// </summary>
publicfloatcharacterRadius=1.5F;
/// <summary>
/// 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 <see cref="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).
///
/// [Open online documentation to see images]
///
/// See: <see cref="cellSize"/>
/// </summary>
[JsonMember]
publicfloatcontourMaxError=2F;
/// <summary>
/// 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).
/// [Open online documentation to see images]
/// The cell size is the width and depth of those boxes. The height of the boxes is usually much smaller
/// and automatically calculated however. See <see cref="CellHeight"/>.
///
/// Lower values will yield higher quality navmeshes, however the graph will be slower to scan.
///
/// [Open online documentation to see images]
/// </summary>
[JsonMember]
publicfloatcellSize=0.5F;
/// <summary>
/// Character height.
/// [Open online documentation to see images]
/// </summary>
[JsonMember]
publicfloatwalkableHeight=2F;
/// <summary>
/// Height the character can climb.
/// [Open online documentation to see images]
/// </summary>
[JsonMember]
publicfloatwalkableClimb=0.5F;
/// <summary>
/// Max slope in degrees the character can traverse.
/// [Open online documentation to see images]
/// </summary>
[JsonMember]
publicfloatmaxSlope=30;
/// <summary>
/// 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 navmeshnotes (view in online documentation for working links).
///
/// [Open online documentation to see images]
/// </summary>
[JsonMember]
publicfloatmaxEdgeLength=20;
/// <summary>
/// Minumum region size.
/// Small regions will be removed from the navmesh.
/// Measured in square world units (square meters in most games).
///
/// [Open online documentation to see images]
///
/// 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.
///
/// [Open online documentation to see images]
/// [Open online documentation to see images]
/// </summary>
[JsonMember]
publicfloatminRegionSize=3;
/// <summary>
/// Size in voxels of a single tile.
/// This is the width of the tile.
///
/// [Open online documentation to see images]
///
/// 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 navmeshnotes (view in online documentation for working links).
/// 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.
/// </summary>
[JsonMember]
publicinteditorTileSize=128;
/// <summary>
/// Size of a tile along the X axis in voxels.
/// \copydetails editorTileSize
///
/// Warning: Do not modify, it is set from <see cref="editorTileSize"/> at Scan
///
/// See: <see cref="tileSizeZ"/>
/// </summary>
[JsonMember]
publicinttileSizeX=128;
/// <summary>
/// Size of a tile along the Z axis in voxels.
/// \copydetails editorTileSize
///
/// Warning: Do not modify, it is set from <see cref="editorTileSize"/> at Scan
///
/// See: <see cref="tileSizeX"/>
/// </summary>
[JsonMember]
publicinttileSizeZ=128;
/// <summary>
/// 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).
/// <see cref="NavmeshCut"/> components also work on a tile-by-tile basis.
/// - Using tiles allows you to use <see cref="NavmeshPrefab"/>s.
/// - 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 <see cref="FunnelModifier"/>s quality setting to high (or using <see cref="RichAI.funnelSimplification"/>) will mostly mitigate this.
///
/// See: <see cref="editorTileSize"/>
///
/// Since: Since 4.1 the default value is true.
/// </summary>
[JsonMember]
publicbooluseTiles=true;
/// <summary>
/// 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
/// </summary>
publicboolscanEmptyGraph;
publicenumRelevantGraphSurfaceMode{
/// <summary>No RelevantGraphSurface components are required anywhere</summary>
DoNotRequire,
/// <summary>
/// Any surfaces that are completely inside tiles need to have a <see cref="Pathfinding.RelevantGraphSurface"/> component
/// positioned on that surface, otherwise it will be stripped away.
/// </summary>
OnlyForCompletelyInsideTile,
/// <summary>
/// All surfaces need to have one <see cref="Pathfinding.RelevantGraphSurface"/> component
/// positioned somewhere on the surface and in each tile that it touches, otherwise it will be stripped away.
/// Only tiles that have a RelevantGraphSurface component for that surface will keep it.
/// </summary>
RequireForAll
}
/// <summary>
/// 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.
///
/// [Open online documentation to see images]
/// 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.
///
/// [Open online documentation to see images]
/// 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).
///
/// [Open online documentation to see images]
/// 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.
///
/// [Open online documentation to see images]
/// 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).
///
/// Note: When not using tiles. OnlyForCompletelyInsideTile is equivalent to RequireForAll.
/// Changes the bounds of the graph to precisely encapsulate all objects in the scene that can be included in the scanning process based on the settings.
/// Which objects are used depends on the settings. If an object would have affected the graph with the current settings if it would have
/// been inside the bounds of the graph, it will be detected and the bounds will be expanded to contain that object.
///
/// This method corresponds to the 'Snap bounds to scene' button in the inspector.