Given a set of points in a plane and an incomplete triangulation of the convex hull of the points (only some edges are given), I'm looking for an algorithm to complete the triangulation (the initial given edges should remain fixed). You can assume that it's possible to complete the partial triangulation but it'd be great if you could also suggest an algorithm for checking that too.
UPDATE" You're given a convex hull of a set of points R^2, which is basically a polygon with some points inside it. We want to triangulate the set of points which is a straightforward matter on itself, but you're also given some edges that any triangulation that you come up with should use those edges."
Perhaps this is a naive answer, but can't you just use a constrained delaunay triangulation? Add the known edges as constraints.
CGAL has a nice implementation. The tool triangle has similar features and is easier to get started with, but has (perhaps) a little less flexibility.
I found out that the book "Computational Geometry: An Introduction" has a detailed treatment of the subject though it doesn't give a ready to implement pseudo-code.
The easiest algorithm is a greedy one which enumerates all the possible edges and then add them one by one avoiding intersection with previously added ages. There is a long discussion in the book about how to reduce the running time to O(n^2 log n).
Then there is a O(n log n) algorithm which first regularizes the convex hull with the given edges and then individually triangulates each monotone polygon.
Related
I have a coordinate set of 2D points that form a closed polygon. I need to generate a set of 2D triangles that distribute the polygon completely.
There are no constrains as such except that the triangles should fill the area of polygon completely. It would be even more helpful if it is a standard algorithm I could implement.
The best way to triangulate general polygons is to compute the constrained Delaunay triangulation - this is a standard Delaunay triangulation of the polygon vertices with additional constraints imposed to ensure that the polygon edges appear in the triangulation explicitly. This type of approach can handle any type of polygon - convex, concave, polygons with holes, etc.
Delaunay triangulations are those that maximise the minimum angle in the mesh, meaning that such a triangulation is optimal in terms of element shape quality.
Coding a constrained Delaunay triangulation algorithm is a tricky task, but a number of good libraries exist, specifically CGAL and Triangle. Both these libraries implement an (optimally) efficient O(n*log(n)) algorithm.
As mentioned above, Delaunay triangulation is a rather complicated algorithm for this task. If you accept O(n^2) running time, you may try Ear Clipping algorithm which is much more easier to understand and to code. The basic idea is the following. Every polygon with >= 4 vertexes and no holes (i.e. its border is a single polyline without self-intersections and self-tangencies) has at least one "ear". An ear is a three consecutive vertexes such that the triangle built on them lies inside the polygon and contains no other points of the polygon inside. If you "cut an ear" (add a triangle to the answer and replace remove the middle point of these three points), you reduce the task to a polygon with less vertexes, and so on. Ears may be trivially (by definition) found in O(n^2) resulting in a O(n^3) triangulation algorithm. There is O(n) ear finding algorithm, and, though it is not very complicated, it is rather long to be described in a couple of phrases.
Furthermore, if you need faster algorithms, you should look something about monotone polygons triangulation and splitting a polygon into monotone ones. There even exists a linear-time triangulation algorithm, but its just as complicated as Delaunay triangulation is.
You may consider Wikipedia article and see an small overview of existing methods there.
If you don't require that the vertices of the triangles be vertices of the polygon, try a triangulation based on a trapezoidal decomposition, as in Fast Polygon Triangulation based on Seidel's Algorithm.
I need an algorithm for computation convex hulls for sorted set of points in 3 and higher dimensions. Also I need in lower part of a convex hull and it is not necessary to construct a whole convex hull.
Are there any efficient and quick algorithms for my purposes?
I believe it was established by Seidel that having the points sorted does not help in terms of asymptotic time complexity, and certainly the lower half can be almost the entire hull, so that will not help either. The randomized incremental (Clarkson and Shor) is perhaps the best choice. Here is an applet illustration of that algorithm: Tufts link.
I implemented this hull algorithm for convex hull finding, posted on GitHub. This is Python and can give you results as:
GPL C++ code for finding the convex hull of points in R3 is available at http://www.newtonapples.net/code/NewtonAppleWrapper_11Feb2016.tar.gz
The algorithm is based on sorting the points in z(x(y)) then sequentially wrapping points into a hull.
Rather appealingly the algorithm has been named after a chocolate.
I have a detailed 2D polygon (representing a geographic area) that is defined by a very large set of vertices. I'm looking for an algorithm that will simplify and smooth the polygon, (reducing the number of vertices) with the constraint that the area of the resulting polygon must contain all the vertices of the detailed polygon.
For context, here's an example of the edge of one complex polygon:
My research:
I found the Ramer–Douglas–Peucker algorithm which will reduce the number of vertices - but the resulting polygon will not contain all of the original polygon's vertices. See this article Ramer-Douglas-Peucker on Wikipedia
I considered expanding the polygon (I believe this is also known as outward polygon offsetting). I found these questions: Expanding a polygon (convex only) and Inflating a polygon. But I don't think this will substantially reduce the detail of my polygon.
Thanks for any advice you can give me!
Edit
As of 2013, most links below are not functional anymore. However, I've found the cited paper, algorithm included, still available at this (very slow) server.
Here you can find a project dealing exactly with your issues. Although it works primarily with an area "filled" by points, you can set it to work with a "perimeter" type definition as yours.
It uses a k-nearest neighbors approach for calculating the region.
Samples:
Here you can request a copy of the paper.
Seemingly they planned to offer an online service for requesting calculations, but I didn't test it, and probably it isn't running.
HTH!
I think Visvalingam’s algorithm can be adapted for this purpose - by skipping removal of triangles that would reduce the area.
I had a very similar problem : I needed an inflating simplification of polygons.
I did a simple algorithm, by removing concav point (this will increase the polygon size) or removing convex edge (between 2 convex points) and prolongating adjacent edges. In any case, doing one of those 2 possibilities will remove one point on the polygon.
I choosed to removed the point or the edge that leads to smallest area variation. You can repeat this process, until the simplification is ok for you (for example no more than 200 points).
The 2 main difficulties were to obtain fast algorithm (by avoiding to compute vertex/edge removal variation twice and maintaining possibilities sorted) and to avoid inserting self-intersection in the process (not very easy to do and to explain but possible with limited computational complexity).
In fact, after looking more closely it is a similar idea than the one of Visvalingam with adaptation for edge removal.
That's an interesting problem! I never tried anything like this, but here's an idea off the top of my head... apologies if it makes no sense or wouldn't work :)
Calculate a convex hull, that might be way too big / imprecise
Divide the hull into N slices, for example joining each one of the hull's vertices to the center
Calculate the intersection of your object with each slice
Repeat recursively for each intersection (calculating the intersection's hull, etc)
Each level of recursion should give a better approximation.... when you reached a satisfying level, merge all the hulls from that level to get the final polygon.
Does that sound like it could do the job?
To some degree I'm not sure what you are trying to do but it seems you have two very good answers. One is Ramer–Douglas–Peucker (DP) and the other is computing the alpha shape (also called a Concave Hull, non-convex hull, etc.). I found a more recent paper describing alpha shapes and linked it below.
I personally think DP with polygon expansion is the way to go. I'm not sure why you think it won't substantially reduce the number of vertices. With DP you supply a factor and you can make it anything you want to the point where you end up with a triangle no matter what your input. Picking this factor can be hard but in your case I think it's the best method. You should be able to determine the factor based on the size of the largest bit of detail you want to go away. You can do this with direct testing or by calculating it from your source data.
http://www.it.uu.se/edu/course/homepage/projektTDB/ht13/project10/Project-10-report.pdf
I've written a simple modification of Douglas-Peucker that might be helpful to anyone having this problem in the future: https://github.com/prakol16/rdp-expansion-only
It's identical to DP except that it pushes a line segment outwards a bit if the points that it would remove are outside the polygon. This guarantees that the resulting simplified polygon contains all the original polygon, but it has almost the same number of line segments as the original DP algorithm and is usually reasonably good at approximating the original shape.
For a polygon defined as a sequence of (x,y) points, how can I detect whether it is complex or not? A complex polygon has intersections with itself, as shown:
Is there a better solution than checking every pair which would have a time complexity of O(N2)?
There are sweep methods which can determine this much faster than a brute force approach. In addition, they can be used to break a non-simple polygon into multiple simple polygons.
For details, see this article, in particular, this code to test for a simple polygon.
See Bentley Ottmann Algorithm for a sweep based O((N + I)log N) method for this.
Where N is the number of line segments and I is number of intersection points.
In fact, this can be done in linear time use Chazelle's triangulation algorithm. It either triangulates the polygon or find out the polygon is not simple.
I know there's a worst-case O(n log n) algorithm for finding the convex hull of a complex polygon and a worst-case O(n) algorithm for finding the convex hull of a simple polygon. Is there a worst-case O(n) algorithm for finding the convex hull of a complex polygon?
A complex polygon is a polygon where the line segments may intersect. Finding the convex hull of a complex polygon is equivalent to finding the convex hull of an unordered list of points.
If your point sets are such that some non-comparison based sorting mechanism (like radix sort) will be faster than comparison based methods, then it seems you can use the Graham scan algorithm (http://www.math.ucsd.edu/~ronspubs/72_10_convex_hull.pdf) to compute it. The time complexity of the Graham scan is dominated by the sorting step. The rest is linear.
I'm pretty sure not. Convex hull on arbitrary point sets can be shown to be equivalent to sorting. We can order an arbitrary point set and connect the points in sequence making it into a complex polygon, thereby reducing the problem on arbitrary point sets to yours.
Here is a link to a proof that convex hull is equivalent to sorting. I'm too damn lazy and too bad a typist to write it out myself.
In general, no there is not a O(n) solution. There is a pixelated version that is better than O(n log n). It is, however, so hobbled in other ways that you'd be crazy to use it in practice.
You render the first polygon (using verts 0, 1, 2) into screen space, then re-render the verts themselves using a distinct ID so they can be identified later. For example, you might clear the frame buffer to RGBA ffffffff and use fffffffe for space that is covered by the convex hull. Each vertex would be rendered using its ID as its RGBA; 00000000, 00000001, etc.
A 16-bit example:
fffffffffffffff
fffffff0fffffff
ffffffeeeffffff
fffffeeeeefffff
ffffeeeeeeeffff
fffeeeeeeeeefff
ff2eeeeeeeee1ff
fffffffffffffff
Checking a new point is a simple lookup in the current frame buffer. If the pixel it occupies is 'shaded' with polygon or with a vertex ID, the new vertex is rejected.
If the new vertex is outside the existing polygon, you find the first pixel between the new vertex and some point inside the convex hull (something in the middle of the first poly works fine) and march along the circumference of the hull - in both directions - until you find yourself on the far side of the hull from the new vertex. (I'll leave this as an exercise to the user. There are plenty of solutions that all suck, from an efficiency perspective.) Fill in the poly defined by these two points and the new vertex with the ID for polygon space - being careful not to erase any vertex IDs - and go on to the next pixel.
When you're done, any pixel which contains a vertex ID that is not completely surrounded by hull IDs is a convex hull vertex.
While the algorithm's complexity is O(n) with the number of vertices, it's deficiencies are obvious. Nobody in their right mind would use it unless they had a ridiculous, insane, staggering number of points to process so that nearly every vertex would be immediately rejected, and unless they could accept the limitation of an aliased result.
Friends don't let friends implement this algorithm.
If your points come from a finite universe (which is always the case in practice) you can do radix sort and then run Andrew's monotone chain algorithm.