Path Planning panel

From HEWIKI
Jump to: navigation, search

The Path Planning panel is a HeroBlade panel, accessible via the Panels menu, which assists with the creation and debugging of the HeroPath AI paths. It allows you to visualize the navigation mesh data and edit the ‘DefaultNavMesh.ini’ file, as well as test pathing solutions. For more information on this system, see Path Planning Technical Information.

Path planning panel.png

Contents

Subpanels

The panel has three subpanels:


Debug Options subpanel

The PathPlanning panel debug options

This section of the panel provides log output from the server and debug options.


Path Planning subpanel

Visualize Navigation Mesh

This checkbox, when selected, allows you to see the current navigation mesh as it exists on the server.

The navigation mesh is visualized as a set of axis-aligned bounding boxes, with lines showing connections between those boxes. Each box, or navigation mesh node, indicates a valid space for a character to walk. The entire surface within this node should be a valid place for a character to stand and walk (see images below).

In general there is no overlap of navigation mesh nodes except along certain boundaries. When the navigation mesh is built, it is done in sections. Each section is designated a ‘PathTask’ during the rebuild phase. This happens because it would require far too much memory to try to build all of the navigation mesh nodes at once for a large area. Instead, nodes are built in sections and, along those section boundaries, it is expected and valid for there to be a slight overlap of nodes.

Visualization of a navigation mesh showing both nodes and connections as color coded wireframe lines
Visualization of just the navigation mesh nodes without the connections
Visualization of the navigation mesh connections only
Visualization of the navigation mesh nodes only as solid color coded boxes. Note how efficiently the nodes describe the surface of the area

When visualizing the navigation mesh, you have the option of toggling bounding boxes on and off as well as whether or not to show connections. You can also visualize the bounding boxes as solid shaded. Using that ‘Path Data Visualization Range’ slider, you can control how far out the navigation mesh will be rendered. It is important to be aware that the rendering of the navigation mesh actually occurs on the server, and is transmitted over the network as a large packet of data. There can be substantial delays in rendering a large amount of navigation mesh data, especially if the server is under heavy load.


Show Dirty Regions

After a change is made to an area, the Physics Server tags the regions of the area which will need updating. These "Dirty" regions can be viewed by selecting the checkbox "Show Dirty Regions".

To see how this works:

Live region updates

The physics server is capable of rebuilding only the edited portion of the navigation mesh on the fly. If you select the checkbox ‘Enable live region updates’, then the physics server will work to patch the navigation mesh to keep up with your editing changes. This is generally fast for small discrete edits but takes much longer for large scale editing changes such as modifying heightmaps. Note that this on-the-fly editing will only affect your current instance, and will have no correlation with the more formal PathMaker-created NavMesh. However, for rapid development, it can be helpful to see more real-time NavMesh changes.

Red indicates navigation mesh nodes that were invalidated by an editing change and are being rebuilt

When dirty regions are being updated, they will show up in red (see above). All pathing requests done while a region update is happening take place against the previously known valid path results. Dirty region updates are ‘patched’ into the old solution, and repeated edits in the same area may create a great deal of additional connections and overlapping nodes.


Color coding

Navigation mesh modes

The color of a navigation mesh mode indicates its type:

Node connections

Path Cache

The visualization options ‘Show Path Cache Valid’ and ‘Show Path Cache Invalid’ are primarily used for debugging/demonstration purposes. When performing ‘string pulling’ the physics server caches success and failure results from previous requests. Toggling these options will provide a visualization of these caches as a set of colored lines. Valid connections show up as light blue lines and invalid connections show up as light red. Each line represents the results of a sweep test to see of a character could have walked directly from the starting point to the ending point.

Results returned from ‘Generate 500 Random Path Requests’
Results of visualizing the Valid Path Cache after 500 searches were performed
Results of visualizing the Invalid Path Cache after 500 searches were performed

No cache lines will show up unless there have been a number of path solutions already run against this area. To test this, go to the top of the Path Planning panel and click the button ‘Generate 500 Random Path Requests’, which does as it sounds. The server will generate 500 random pathing requests in the area and provide a brief visualization of the results obtained. Having performed this operation the path cache will be populated and as you fly the camera around the lines should show up on the visualization.

Custom Path Generation Properties subpanel

Via Camera Mode

Path Planning Custom Path Generation editor. Supports editing, testing, and publishing of navigation mesh generation options

The INI file which controls how the navigation mesh is generated can be edited directly inside HeroBlade using the PathPlanning panel. You can preview changes to these settings by using the ‘TestBuild’ button. When you perform the ‘TestBuild’ operation, the new settings will be applied only to the currently visible region of the navigation mesh. This is extremely useful for experimentation and tuning of parameter changes.

If you wish to make a global change to all navigation meshes, then click the button ‘Publish as New Master Settings’. This will write out the file ‘DefaultNavMesh.ini’ to the root level of your repository. Remember that existing navigation meshes will not be rebuilt using these settings unless there is an editing change to that area or you remember to bump the ‘build_version’ number.

You can also make changes that apply only to the current area you are working in. You accomplish this by clicking the button marked ‘Publish Custom Settings’. This writes a file ‘area.ini’ in the same Repository folder as the corresponding ‘area.dat’ file.

To remove the custom settings for an area and have it revert back to the global navigation mesh settings, select ‘Delete Custom Settings’.

Example of a path solution generated by marking a ‘FROM’ and ‘TO’ location in an area

You can test the path solver in the following manner:

If a path can be found, it will show up as a set of nodes and lines. (See above)

Via mouse position

Example of a path solution generated by ‘Visualize Raycast Paths’

Another useful way to test the pathing system is to enable the checkbox ‘Visualize Raycast Paths’. Once you do this, the pathing system will try to generate a valid path to whatever location your mouse is pointing at. This happens in real-time. If you want to lock the ending location at a particular spot, hold down the SHIFT key, and pathing requests at the current mouse location will be paused.

See also

Personal tools
Namespaces
Variants
Actions
Navigation
Toolbox