The A* Inspector

Multithreading puts pathfinding in another thread, this is great for performance on 2+ core computers since the framerate will barely be affected by the pathfinding at all.

• None indicates that the pathfinding is run in the Unity thread as a coroutine

• Automatic will try to adjust the number of threads to the number of cores and memory on the computer. Less than 512mb of memory or a single core computer will make it revert to using no multithreading.

It is recommended that you use one of the "Auto" settings that are available. The reason is that even if your computer might be beefy and have 8 cores. Other computers might only be quad core or dual core in which case they will not benefit from more than 1 or 3 threads respectively (you usually want to leave one core for the unity thread). If you use more threads than the number of cores on the computer it is mostly just wasting memory, it will not run any faster. The extra memory usage is not trivially small. Each thread needs to keep a small amount of data for each node in all the graphs. It is not the full graph data but it is proportional to the number of nodes. The automatic settings will inspect the machine it is running on and use that to determine the number of threads so that no memory is wasted.

The exception is if you only have one (or maybe two characters) active at time. Then you should probably just go with one thread always since it is very unlikely that you will need the extra throughput given by more threads. Keep in mind that more threads primarily increases throughput by calculating different paths on different threads, it will not calculate individual paths any faster.

Note that if you are modifying the pathfinding core scripts or if you are directly modifying graph data without using any of the safe wrappers (like AddWorkItem) multithreading can cause strange errors and pathfinding stopping to work if you are not careful. For basic usage (not modding the pathfinding core) it should be safe.

This setting is an enum of the type ThreadCount

ThreadCount

Number of threads to use.

AutomaticLowLoad= -1
AutomaticHighLoad= -2
None= 0
One= 1
Two
Three
Four
Five
Six
Seven
Eight

When searching for the nearest node to a point, this is the limit (in world units) for how far away it is allowed to be.

This is relevant if you try to request a path to a point that cannot be reached and it thus has to search for the closest node to that point which can be reached (which might be far away). If it cannot find a node within this distance then the path will fail.

The heuristic, often referred to as just 'H' is the estimated cost from a node to the target. Different heuristics affect how the path picks which one to follow from multiple possible with the same length

This setting is an enum of the type Heuristic

Heuristic

How to estimate the cost of moving to the destination during pathfinding.

Manhattan	Manhattan distance. See https://en.wikipedia.org/wiki/Taxicab_geometry
DiagonalManhattan	Manhattan distance, but allowing diagonal movement as well. Note This option is currently hard coded for the XZ plane. It will be equivalent to Manhattan distance if you try to use it in the XY plane (i.e for a 2D game).
Euclidean	Ordinary distance. See https://en.wikipedia.org/wiki/Euclidean_distance
None	Use no heuristic at all. This reduces the pathfinding algorithm to Dijkstra's algorithm. This is usually significantly slower compared to using a heuristic, which is why the A* algorithm is usually preferred over Dijkstra's algorithm. You may have to use this if you have a very non-standard graph. For example a world with a wraparound playfield (think Civilization or Asteroids) and you have custom links with a zero cost from one end of the map to the other end. Usually the A* algorithm wouldn't find the wraparound links because it wouldn't think to look in that direction. See https://en.wikipedia.org/wiki/Dijkstra%27s_algorithm

The heuristic is the estimated cost from the current node to the target. The different heuristics have roughly the same performance except not using any heuristic at all (#None) which is usually significantly slower.

In the image below you can see a comparison of the different heuristic options for an 8-connected grid and for a 4-connected grid. Note that all paths within the green area will all have the same length. The only difference between the heuristics is which of those paths of the same length that will be chosen. Note that while the Diagonal Manhattan and Manhattan options seem to behave very differently on an 8-connected grid they only do it in this case because of very small rounding errors. Usually they behave almost identically on 8-connected grids.

Generally for a 4-connected grid graph the Manhattan option should be used as it is the true distance on a 4-connected grid. For an 8-connected grid graph the Diagonal Manhattan option is the mathematically most correct option, however the Euclidean option is often preferred, especially if you are simplifying the path afterwards using modifiers.

For any graph that is not grid based the Euclidean option is the best one to use.

If a value lower than 1 is used, the pathfinder will search more nodes (slower). If 0 is used, the pathfinding algorithm will be reduced to dijkstra's algorithm. This is equivalent to setting heuristic to None. If a value larger than 1 is used the pathfinding will (usually) be faster because it expands fewer nodes, but the paths may no longer be the optimal (i.e the shortest possible paths).

Usually you should leave this to the default value of 1.

This setting is an enum of the type HeuristicOptimizationMode

HeuristicOptimizationMode

None
Random
RandomSpreadOut
Custom

If toggled, graph updates will batched and executed less often (specified by graphUpdateBatchingInterval).

This can have a positive impact on pathfinding throughput since the pathfinding threads do not need to be stopped as often, and it reduces the overhead per graph update. All graph updates are still applied however, they are just batched together so that more of them are applied at the same time.

However do not use this if you want minimal latency between a graph update being requested and it being applied.

This only applies to graph updates requested using the UpdateGraphs method. Not those requested using RegisterSafeUpdate or AddWorkItem.

If you want to apply graph updates immediately at some point, you can call FlushGraphUpdates.

If batchGraphUpdates is true, this defines the minimum number of seconds between each batch of graph updates.

This can have a positive impact on pathfinding throughput since the pathfinding threads do not need to be stopped as often, and it reduces the overhead per graph update. All graph updates are still applied however, they are just batched together so that more of them are applied at the same time.

Do not use this if you want minimal latency between a graph update being requested and it being applied.

This only applies to graph updates requested using the UpdateGraphs method. Not those requested using RegisterSafeUpdate or AddWorkItem.

Graphs will be prioritized based on their order in the inspector. The first graph which has a node closer than prioritizeGraphsLimit will be chosen instead of searching all graphs.

Additional searches will normally only be done on the graph which in the first fast search seemed to have the closest node. With this setting on, additional searches will be done on all graphs since the first check is not always completely accurate.
More technically: GetNearestForce on all graphs will be called if true, otherwise only on the one graph which's GetNearest search returned the best node.
Usually faster when disabled, but higher quality searches when enabled. When using a a navmesh or recast graph, for best quality, this setting should be combined with the Pathfinding.NavMeshGraph.accurateNearestNode setting set to true.

This does not include loading from the cache. If you disable this, you will have to call AstarPath.active.Scan() yourself to enable pathfinding. Alternatively you could load a saved graph from a file.

Use less debugging to improve performance (a bit) or just to get rid of the Console spamming. Use more debugging (heavy) if you want more information about what the pathfinding scripts are doing. The InGame option will display the latest path log using in-game GUI.

This setting is an enum of the type PathLog

PathLog

How path results are logged by the system.

None	Does not log anything. This is recommended for release since logging path results has a performance overhead.
Normal	Logs basic info about the paths.
Heavy	Includes additional info.
InGame	Same as heavy, but displays the info in-game using GUI.
OnlyErrors	Same as normal, but logs only paths which returned an error.

This setting is an enum of the type GraphDebugMode

GraphDebugMode

How to visualize the graphs in the editor.

SolidColor	Draw the graphs with a single solid color.
G	Use the G score of the last calculated paths to color the graph. The G score is the cost from the start node to the given node. See https://en.wikipedia.org/wiki/A*_search_algorithm
H	Use the H score (heuristic) of the last calculated paths to color the graph. The H score is the estimated cost from the current node to the target. See https://en.wikipedia.org/wiki/A*_search_algorithm
F	Use the F score of the last calculated paths to color the graph. The F score is the G score + the H score, or in other words the estimated cost total cost of the path. See https://en.wikipedia.org/wiki/A*_search_algorithm
Penalty	Use the penalty of each node to color the graph. This does not show penalties added by tags. See Graph Updates during Runtime Pathfinding.GraphNode.Penalty
Areas	Visualize the connected components of the graph. A node with a given color can reach any other node with the same color. See Pathfinding.HierarchicalGraph https://en.wikipedia.org/wiki/Connected_component_(graph_theory)
Tags	Use the tag of each node to color the graph. See Working with tags Pathfinding.GraphNode.Tag
HierarchicalNode	Visualize the hierarchical graph structure of the graph. This is mostly for internal use. See Pathfinding.HierarchicalGraph

This will show the search tree for the latest path.