Navigation charts and navigation Grids

Overview

Navigation charts are still a useful method to replace Navigation grids, and may have some advantages depending on the game environment. This article discusses several ways to generate a navigation chart: from an automatic method based on the gridded area, to a fully automated method derived from the navigation area and double triangle graphics.

This article uses a general computational geometric algorithm and an algorithm inspired by Image Processing (the author may mean to use some graphics processing algorithms ). An open-source computer vision library opencv ([bradski2008], [OCV]) may be used to implement the image processing technology discussed here.

We also talked about hierarchical navigation charts, which bring great opportunities for space optimization.

Overview: navigation networks and navigation charts

Now there are more and more middleware processing products for game proxy navigation. We do not plan to review or introduce them, or even mention any of them. Although they can provide solid solutions for many typical scenarios, building a custom navigation system is the only choice for many projects. Therefore, it is important for engineers and designers to understand (as needed) What technologies should be chosen.

There are two main ways to create and provide navigation information for the game (the original article is game levels, and it feels that translation can make sense for the game. One is based on the navigation grid, and the other is to use a navigation chart (see the method for introduction to [snook2000] of stout2000 navigation data, especially the navigation grid ). As shown in figure 1: two methods in the same test environment represent navigation data in the zone.

Figure 1: path strength selected when connecting points A to B in the navigation network and navigation map

The game proxy can use the navigation network to find the path from A to B through an algorithm. We will briefly introduce this algorithm: first, for starting point A, this algorithm finds the navigation mesh ta containing a and the navigation mesh triangle TB containing the destination B. then you can create a shortest path that passes through the navigation mesh (from A to B). This path consists of a string of connected Triangle List L from triangle TA to Triangle TB. This is usually implemented through the * algorithm.

Because any path composed of navigation triangles is valid, knowing the list l allows us to connect A to B using a piecewise linear path. Therefore, as long as l is calculated, our task is completed, at least roughly. We usually need to further modify the path, because l looks too rigid (the original is robotic), which can be clearly seen from this situation. Although the beauty of improvement paths is a fascinating topic, we will not go into it.

The navigation mesh can often be generated from collision ry automatically, manually, or at runtime, however, this will be challenged by performance restrictions, unless we only process a small number of grids at the same time.

A navigation chart solves this problem by setting up two-dimensional navigation data. The technology is similar to the Technology Based on navigation grid in many aspects. A navigation chart is based on nodes. A node does not contain all the navigation areas, but provides useful markup as a road sign (waypoints). A series of two-dimensional elements (such as circles and quadrilateral) can be used as nodes in a navigation chart. All paths in the node are valid. If the restrictions are met, the path from any point in the environment to a point in any node (usually a straight line) is valid, the most common restriction is that the path cannot interwork with the collision ry. In addition, we need to exclude mountains, steep slopes, and water surface (meaning mountains, steep slopes, and the water surface does not meet the conditions ).

It is often said that collision detection along this path and other terrain feature restrictions consume a lot of CPU. We can use blocking primitives to represent non-navigation areas (equivalent to using some points to enclose a face, indicating that this area cannot be crossed ), then, we only need to check whether the image is in the intersection with these points. These blocking points are very simple and often use boxes (orientation or axis alignment) or cylinders, which allows for very efficient light intersection tests on blocking points. Note: navigation grids often do not require additional congestion points because all information about the navigation areas is included in the navigation grid.
2 represents a column, in which the translucent axis alignment of the red box (the outline is white, note: Too Many attributions, do not know how to translate ...) along the walls, garbage bins and other obstacles. The navigation chart has yellow-green nodes connected with bright yellow edges, which is equivalent to the lower left corner of the test environment in Figure 1. (The door is locked, so there is no indoor connection in the test environment .)

 

Figure 2: Blocking points and navigation charts

With a navigation chart and a series of blocking points, we can use the following algorithm to construct a path: Starting from the starting point a, we know the nearest navigation node Na, therefore, the line from A to Na is not blocked. Similarly, we can know the Nb nodes closest to B. Using the * algorithm, we can find a series of nodes connecting NA TO Nb. 3 is composed of a navigation chart and a blocking point (pale pink box) in Figure 1.

 

Figure 3: navigation chart and blocking point
A navigation chart has some advantages over a navigation grid. First, you can easily include the navigation slots of objects into the environment. For example, we need a proxy to access the door, and then we can open the door in a certain way. The slot in the navigation chart indicates the desired position near the door, which can be changed to another node in the chart. There may be other additional attributes (directions may also contain an indication, indicates the type of action used to open the door ).

Secondly, because the navigation chart does not use a very direct way to segment the geometric chart like the navigation grid, the hierarchical design can be very flexible. Nodes are generally used as objects in hierarchical design tools, so they are easier to operate on triangles than on a navigation mesh (designers should be concerned with maintaining the topology of the mesh. By adjusting the node location in the graph, the designer can introduce some subtle (and less subtle) effects to the path in the environment.

Needless to say, it takes a lot of time to manually generate and adjust a navigation chart. Another drawback is that these manually created charts are difficult to update. If the geographical shape changes during the design process, you need to be especially careful when you want to modify them during game operation. To sum up, we can conclude that the navigation grid is more suitable than that where the navigation data needs to be automatically generated, while the navigation map is suitable for the situations that the terrain designer needs and must manually enter. This puts forward the necessity of simplifying the complexity of manual creation and maintenance of navigation charts.
Manually generate a navigation chart and confirm
You can use many technologies to generate a navigation chart.
Optimal density of a navigation chart
On the one hand, a navigation chart must be dense enough to provide a navigation node in the environment to access each valid location. On the other hand, after being too dense, it is difficult to manually create a graph first, which will lead to a longer computing time for the * algorithm. It also easily leads to robotic proxies: they tend to stick to nodes without obvious shortcuts. Surprisingly, a sparse graph may also increase the computing volume during running or invalidate the algorithm, if it does not take the following into account, as shown in figure 4.

Figure 4: select the nearest node on the other side of the wall using the * Algorithm
In Figure 4, the proxy is placed at location A. When you are looking for the nearest node, the marked red dot is selected. Obviously, this is the starting node of the Error. Therefore, it is necessary to use the ray detection proxy point and the blocking point to prevent the Proxy from penetrating the wall when going to the destination. If the selected node is detected and removed, you need to find a node that is near and can be directly reached. This may be time-consuming and depends on the Environmental complexity.

Therefore, you can use an offline program to verify whether the above problems exist in the navigation chart, instead of relying on the runtime code to find and restore the situation where there are too few nodes (it is too difficult to translate according to the original text. from below, I should translate it according to my own understanding, click here. If there are any errors, please do not correct them ).

Figure 5: connection between nodes: The left graph indicates that the proxy may need a specific position to make the path not to intersection with the blocking body.

The right figure means that, because the boundary between the two navigation nodes is sufficiently wide, no blocking will occur in any case.

Therefore, it is not only the border of a graph that does not need to interwork with an obstacle, but also must have no obstacle in a wider area between two adjacent nodes, this area is limited by the external tangent between the two-dimensional cylinder and the cylinder. This requirement is not easily met when you manually create a navigation chart.
A useful technique to prevent agents from getting too close to the wall is summarized by minkoski and widely used in robotics. The main idea of proxy is briefly described as follows: Assume that proxy has a sphere that can enclose proxy and set its radius to R. Obviously, we want the proxy to be at least R away from the wall. Assuming that the original blocking body is drawn strictly according to the size, we only need to follow the obstacle boundary, expand the boundary r (I do not know how to describe it. The idea is very simple. You can see the picture ). The expansion process should be automatically generated during the development process (that is, the obstacle size is directly zoomed in), and can also be processed when the program is running. This technology is described as follows:

 

Figure 6: Red expansion obstacle covers the original obstacle (dark red) and navigation chart

To sum up, it is best to avoid generating a navigation chart manually, because it is very easy to make mistakes and time-consuming. We should find a fully automatic generation technology or sometimes make comprehensive use of manual and automatic methods. From this perspective, this is the main factor restricting the manual generation of navigation charts.

To be continued, original address: http://www.gamedev.net/page/reference/index.html/_/reference/programming/artificial-intelligence/navigation-graph-generation-r2805