7

I'm working on path finding for an RTS game, where I am building a navigation mesh from the game's grid.

I have written an algorithm similar to Marching Squares which creates and simplifies the borders between the walkable and unwalkable regions of the map. Now I have a "mesh" consisting of only edges. I need to triangulate this mesh so that the final triangulation contains the initial edges, and then I can remove the unwalkable regions to create holes in the navigation mesh. For example, I need to do this...

enter image description here

The triangles represent the walkable regions of the map. The holes represent unwalkable regions such as mountains or buildings. The mesh can be considered 2D, since the height is irrelevant. This is obviously a very simplified case. The navigation mesh in the game will consist of thousands of vertices and many holes, but I may break it down into smaller chunks for dynamic updating.

I have looked at constrained Delaunay Triangulation algorithms, which first create a Delaunay Triangulation of the points, and then remove any triangles that intersect the constrained edges, then re-triangulates the removed triangles.

This seems a little redundant for my purposes. My mesh does not need to be Delaunay, and it consists completely of constrained edges, so I'd like to skip doing the extra triangulations if possible. Is there a better algorithm for this? I have looked and looked, and have only been able to find constrained Delaunay algorithms. Or maybe I'm wrong, and a constrained Delaunay algorithm would be best?

I've done navigation mesh path finding from scratch before, but never had to generate the navigation mesh myself. Triangulation algorithms are new to me. Any insight?

Janz Dott
  • 325
  • 4
  • 13
  • Since you don't have special requests on triangles, simpler approach like [polygon triangulation](http://en.wikipedia.org/wiki/Polygon_triangulation) is better to use than Delaunay. – Ante Dec 08 '13 at 20:57
  • I looked at the Ear-Clipping method, which seems to be slightly slower than a Delaunay triangulation, but would require me to sort my vertices in looping orders, right? – Janz Dott Dec 08 '13 at 21:06
  • Now I realize that you have only edges. In each case you will need to connect and orient edges, find for a part is inside some other part (to know is it a hole or not) and then triangulate polygon with a holes. Holes can be removed by adding 2 same edges from a hole to polygon boundary or other hole. Ear clipping is simple method and with space partitioning (BSP tree, quad tree, ...) it is faster than O(n^2). – Ante Dec 08 '13 at 21:34
  • I'm very familiar with space partitioning, so I think I'll give it a try. From what I read, it said that the vertices of the holes must be wound in the opposite direction of the vertices of the outer polygon. Ordering the vertices in clockwise and counterclockwise order for each edge loop will be another algorithm in its own, since they are currently not in order whatsoever, and are not grouped by edge loop. How fun this will be... – Janz Dott Dec 08 '13 at 21:55
  • Just a thought, "edge mesh" is created from a map which has terrain probably described with some areas (polygons) and edges are where terrain change (e.g. field to mountain.) If areas are simple then there neighbourhood information can be used to make mesh, without going to general triangulation. – Ante Dec 08 '13 at 22:45
  • The shapes of the walkable and unwalkable areas are pretty complex, so I don't see a way of doing that. The terrain is procedurally generated, and buildings must be able to be placed/removed at any position. – Janz Dott Dec 08 '13 at 23:07
  • Got my edges sorted by their respective loop and winding direction, but I realized Ear Clipping won't work for me because I have islands that aren't part of the main walkable area. It could be done, but it's too complex. I almost have a naive O(n^2) Delaunay triangulator done, then I'll have to add the edges one by one. – Janz Dott Dec 09 '13 at 03:12
  • My non-constrained Delaunay triangulator is working, and it actually includes almost all of the edges on its own without being constrained. Maybe it's because the vertices are aligned to a grid. But it works very well and performs better than expected, so I'm happy! – Janz Dott Dec 09 '13 at 05:25

1 Answers1

2

Fernandez et al 2008 seems to be close to the state-of-the-art when it comes to the problem of decomposing complex domains. If you're looking for (possibly simpler) alternatives, the authors list other possible algorithms in the second paragraph of p370.

Andy Jones
  • 4,723
  • 2
  • 19
  • 24