Why not include 'rcBuildPolyMeshDetail'?

General Recast graph
#1

BuildPolyMesh (rcBuildPolyMesh in Recast), which includes triangulation, is straightly followed by CreateTile.
There is supposed to be a step rcBuildPolyMeshDetail in between, as shown in Build Process.
It will smooth the edges according to heightfield info so that generated NavMesh will get adjacent to real mesh.

Is it for some purpose that it isn’t it included in A*?

BTW, I saw in code

		/** Builds a polygon mesh from a contour set.
		 *
		 * \param cset contour set to build a mesh from.
		 * \param nvp Maximum allowed vertices per polygon. \warning Currently locked to 3.
		 * \param mesh Results will be written to this mesh.
		 */
		public void BuildPolyMesh (VoxelContourSet cset, int nvp, out VoxelMesh mesh) {
			AstarProfiler.StartProfile("Build Poly Mesh");

			nvp = 3;

nvp is set to 3, so generated meshes are already triangles?

#2

It was a long time since I looked at that part of the recast code, but if I recall correctly, the detail mesh is a completely separate mesh from the navmesh. Instead it is used to provide height information for the agent so it knows where the ground is. However I think using the physics system is usually a better fit for this as it is already highly optimized and would provide essentially the same information.

Yes, my package triangulates the mesh completely. It does not use convex polygons with more corners.

#3

As far as I have researched, rcBuildPolyMeshDetail will create a new object dmesh (of class rcPolyMeshDetail).

It will go along every edge with a sampling distance and check if the sample point’s height deviation is acceptable compared with that in compact height field. If not, it will insert new vertices, thus kind of fixing unacceptable height deviation, and that is the main difference between dmesh and mesh.

As A* does not have this step and I really need this, I would probably implement on my own. If I do make it, I wonder whether there is a place I can submit a pull request or something so that it can be included in A*.

#4

Hi

But the poly mesh detail isn’t used for pathfinding still, right? It’s just used for positioning the character along the y axis?

#5

By logic, new vertices will be inserted thus changing recast graph although it contributes to y axis coordinates only as you said.
And this will help fix contours that do not align with mesh and generate better graph.

#6

Only if the detail mesh is actually used for pathfinding, which if I recall correctly (correct me if I am wrong) it is not. Also. Why do you need the extra y coordinate info? Perhaps it could be solved in another way.

#7

I have finished my work: https://github.com/MoYummy/rcBuildPolyMeshDetail

You can see the difference:

image
image847×314 61 KB

image
image880×329 61.9 KB

#8

I would so much like to see this included.
It is very useful in multilayer graphs.
Some time ago I was asking about this, since I got some problems with following the path, especially when character was so far away in y from the path.

Best solution would be to search for path on simpler (not detailed mesh) and than project this path on more detailed one.

@moyummy do you know how your solution works on a bumpy terrain that is not made from such a flat layers ?

#9

You can create a flat terrain for scanning and add texture with normal mapping so that it looks like bumpy.

Or you can refer to capsule collider of character. You can add collider, which is flat, and use collider for rasterization instead of mesh.

#10

I’m asking more about if your solution of detailed mesh Is going to work properly on such a bumpy terrain. Because your example shows only simple example of flat surfaces.

#11

The logic is quite simple: sample along edges, compare height and insert vertices.
Bumpy terrains will have bumpy NavMesh.