Path Planning panel
(→Via Camera Mode) |
(→Live region updates: updated image for Sapphire) |
||
| Line 55: | Line 55: | ||
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 [[heightmap]]s. 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. | 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 [[heightmap]]s. 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. | ||
| − | [[Image: | + | [[Image:HeroBladePathPlanningLiveRegionUpdate.png|thumb|center|800px|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. | 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. | ||
Revision as of 15:27, 31 October 2012
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.
Contents |
Subpanels
The panel has three subpanels:
Debug Options subpanel
This section of the panel provides log output from the server and debug options.
Path Planning subpanel
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.
 |
 |
 |
 |
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:
- Ensure that "Visualize Navigation Mesh" is selected
- Green nodes should appear in the viewport.
- If nodes do not appear, check the Path Data Visualization Range slider on the panel, and move it back and forth, as the camera may be too far away from the nodes to see them.
- Ensure that "Show Dirty Regions" is checked.
- Select an object within the viewport, and move it.
- The areas which are now ‘dirty’ will show up as an orange wireframe axis-aligned bounding box.
- Note that you may need to move the camera slightly, to get the orange bounding boxes to appear. This is done to save on bandwidth being sent from the server to the client.
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.
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:
- Green: Terrain
- White: Non-terrain
- Blue: The node is on the surface of water
- Yellow: The node is underwater
- Peach: Node is marked as ‘avoid’
- Teal: Node is marked as ‘prefer’
- Red: Node is being rebuilt
- Node connections
- Green indicates a bi-directional connection.
- Red indicates a uni-directional connection. An arrowhead indicates the direction.
- Light blue indicates lower cost connections.
- Dark green indicates higher cost connections
- Dark gray indicates dead/disabled' 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.
 |
 |
 |
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
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’.
You can test the path solver in the following manner:
- In fly mode, move your viewpoint to a starting location.
- Click the button marked ‘Capture Path FROM Location’.
- Fly the camera to your desired ending position
- Click the button marked ‘Capture Path TO Location’
If a path can be found, it will show up as a set of nodes and lines. (See above)
Via mouse position
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.
