Mark Bayazit's Algorithm
Evolution
My algorithm was built incrementally based on a few simple observations:
- A polygon can be broken into convex regions by eliminating all reflex vertices
- Eliminating two reflex vertices with one diagonal is better than eliminating just one
- A reflex vertex can only be removed if the diagonal connecting to it is within the range given by extending its neighbouring edges; otherwise, its angle is only reduced
From this, the algorithm naturally presents itself. Start at an arbitrary vertex, and iterate around the polygon until we find a reflex vertex i. Extend the edges incident at i until they hit an edge, like so:
![](images/range.gif)
Case 1
If there are no vertices in this range, create a new (Steiner) vertex in the center and connect to that.
![](images/case1.gif)
Case 2
If there are one or more vertices in this range, connect vertex i to the closest one.
![](images/case2.gif)
Case 3
However, sometimes this can fail.
![](images/case3.gif)
This can easily be fixed with a post-processing or cleanup step by iterating over all the added diagonals and removing the ones that are no longer needed.
Case 4
As pointed out by Dr. Bhattacharya, this does not always work either.
![](images/case4.gif)
Edges ab and bc could be replaced with ac for a better solution. This can be fixed too, however. Notice that vertex b is in c's range, but c is not in b's range. However, a is in c's range and vice versa; this means that both reflex vertices can be removed with a single diagonal. Therefore, the diagonal ac should be preferred over the diagonal bc.
Thus, vertex i should connect to the vertex with the highest priority. From highest to lowest the priorities are:
- closest reflex vertex that can also be eliminated (it's better to eliminate two than one)
- closest reflex vertex (it's better to reduce the angle of a reflex than not at all -- this will give us more choices when trying to eliminate it later)
- closest vertex (less chance of the new diagonal intersecting an existing edge)
Case 5
The reason for using the closest vertex was that I thought it couldn't be blocked. However, I overlooked this case:
![](images/case5.gif)
Again, this can easily be fixed with a visibility check. It does make the algorithm more complex, however.
Shortcomings
With all these checks in place, my algorithm should produce the optimal solution most of the time and is still asymptotically faster than existing solutions. However, there are still two general cases where it will fail, and are not easily resolvable.
Case 1
My algorithm is not optimal for all solutions that require Steiner points. For example, it cannot handle four leaf clover-like polygons.
![](images/case6a.gif)
![](images/case6b.gif)
Case 2
Worse yet, the "closest vertex" heuristic can be exploited to make my algorithm produce poor results for cases without Steiner points too.
![](images/case7.gif)
Diagonals ab and cd, could be replaced with a single diagonal ac to reduce the solution by one polygon.
Optimality
This algorithm uses Steiner points, but is not optimal for either case (with or without Steiner points). However, it does tend to produce optimal results most of the time, in practice.
Complexity
- It takes O(n) time to find all r reflex vertices.
- It takes 2*O(n) time to extend the incident edges of a reflex vertex (the time to check a ray against all edges)
- It can take up to O(n) time to check all the vertices in range for the best candidate
- The algorithm is recursive, but since it eliminates one reflex vertex during each iteration, and only takes O(n) time per reflex vertex, the entire algorithm takes O(nr) time.
Improvements
One way to get around the last case is to form a hybrid method with Keil's algorithm. Vertex a could have been connected to vertices b, c, or e and have made them both non-reflex in each case. Thus, we could try all three of them, and take the best solution, just as in Keil's algorithm. If speed is a concern, we could only examine only, say, the top five highest priority vertices.
Screenshots
![](images/thumbs/bayazit1.gif)
![](images/thumbs/bayazit2.gif)
![](images/thumbs/bayazit3.gif)
![](images/thumbs/bayazit4.gif)
![](images/thumbs/bayazit5.gif)
![](images/thumbs/bayazit6.gif)
Download
polydecomp-bayazit.zip (268 kB)
Tested on Ubuntu 8.10 64-bit.
Requirements:
Libraries: FTGL (for fonts), FreeType2 (needed by FTGL), GLFW (for windows and keyboard input), OpenGL
Software: CMake (if it doesn't build)
To build and run:
cmake .
make
./conv
Update Oct 2015: Source code can now be found on BitBucket.
- C# version (with updates from Farseer Physics and Yogesh Kulkarni)
- C++ version