I have a set of polygons and I want to test intersection between it and a segment.
I checked the manual but I cannot find a matching function.
The intersection between points, lines, segments, triangles, planes do exist.
And the intersection between polygons are also there.
My question is:
Is there such a function?
If not, does it mean I need to break down the polygons into segments and do intersection among these segments? (The reason that I am reluctant to do this is, I thought CGAL might in fact use this way to do intersections between polygons. How come there is no such a function for intersecting a line and a polygon?) Or is there any other better way to do it?
The easiest method is to create a Polygon_set_2 object which may contain several polygons. To test an intersection of an external polygon with this set you simply apply the do_intersect method.
For example:
typedef CGAL::Polygon_set_2<Kernel, std::vector<Kernel::Point_2>> Polygon_set_2;
Polygon_set_2 ps;
Polygon_2 poly;
Polygon_2 line; // line is a polygon defined by 2 points
ps.insert(poly);
bool intersect = ps.do_intersect(line);
More on polygon_set_2:
http://www.cgal.org/Manual/3.2/doc_html/cgal_manual/Boolean_set_operations_2_ref/Class_General_polygon_set_2.html
http://www.cgal.org/Manual/3.2/doc_html/cgal_manual/Boolean_set_operations_2_ref/Class_Polygon_set_2.html
I hope it's clear,
Kiril
Related
I am using boost geometry and I am trying to calculate a "bounded" polygon (see image below) from intersecting polylines (linestrings 2d in Boost geometry). Currently, my approach is i) to get all the intersection points between these lines and then ii) "split" each line at the intersection points. However, this algorithm is a little bit exhaustive. Does anyone know if boost geometry has something more efficient for this?
Moreover, how could I get the segment (or vector of points) for each linestring that lie withing two intersection points? For example, for the green linestring, if I have the two red intersection points, how can I get the linestring between these two points (vector of points containing the two red intersection points and the two interior blue points)? Is there any "split"-like functionality in boost geometry?
Any suggestion is much appreciated. Thanks a lot in advance.
From the given description, it seems that the (poly)lines intersect in pairs to form a single loop, so that the inner polygon is well defined. If this is not true, the solution is not unique.
As the number of lines is small, exhaustive search for the pairwise intersections will not be a big sin. For 5 (poly)lines, there are 10 pairs to be tried, while you expect 5 intersections. Forming the loop from the intersections is not a big deal.
What matters most is if Boost Geometry uses an efficient algorithm to intersect polylines. Unsure if this is documented. For moderate numbers of vertices (say below 100), this is not so important.
If the number of points is truly large, you can resort to an efficient line segment intersection algorithm, which lowers the complexity from O(n²+k) down to O((n+k) log n). See https://en.wikipedia.org/wiki/Bentley%E2%80%93Ottmann_algorithm. You can process all polylines in a single go.
If your polylines have specific properties, they can be exploited to ease the task.
I'm facing the following problem: I'm given a set of coordinates on an integer grid that define the vertices of a polygon. The polygon is guaranteed to be convex. It's proven that such a polygon can always be cut into 4 equal area parts by 2 orthogonal lines. Let's call the point of these lines' intersection P.
Given that set, I should calculate the coordinates of P within the polygon and the angle the lines need to be turned on so that the lines cut the polygon into 4 equal parts.
I realise that, put generally, the cake cutting problem has no "good" solution. But this particular case of it should.
I've searched for an algorithm to solve that problem, but found nothing useful.
Where should I look?
My approach would be to calculate the coordinates of the centre of the polygon (that can be done more or less easily), place Pthere and then "wiggle" the lines until the areas of the parts match. But that sounds too inelegant.
UPD: that's the problem I'm dealing with. Perhaps this question should be suspended until I come up with actual code questions.
Here is a partial sketch of the solution:
Choose an arbitrary direction and find the line parallel to that direction that splits the polygon in two. To achieve this, draw a line by every vertex to decompose the polygon in slabs. The respective areas of the slabs will tell you what slab the desired line intersects. Simple linear interpolation will give the exact location of the line.
Now your polygon is split in two convex polygons. For each halve, repeat the above procedure using the perpendicular direction. In general, you will get two distinct splitters, and what remains to be done is to find the direction such that they do coincide.
In the given direction, the splitters intersect four specific edges of the polygon. If you slightly rotate, they still intersect the same four edges. You can decompose a full turn in angular ranges such that the four intersected edges remain the same.
Knowing the four intersected edges, you can establish the relation that tells you the distance between the two perpendicular splitters as a function of the angle. Then you can compute the angle at which the two splitters coincide, and check if this angle belongs to the range defined for these edges.
By trying all ranges in turn, you will find the solution.
Note: the limits of the angular ranges correspond to directions parallel or perpendicular to the lines joining two vertexes.
Given a bunch of convex polygons layed out like a house truss, is there a way to compute the empty area, or get a polygon for each of those "holes" between the polygons?
I tried starting from any given polygon and then finding the intersections between some of the lines of the polygons and somehow I'm stuck at how to properly select which lines to use for the intersections.
I then tried to verify for a clockwise detection of the area but it seem that my algo for determining the CW/CCW of two lines does not work as, I think, it act as if the lines have the same origin instead of being "in sequence" from each other.
According to comments the solution is quite easy
1.prepare data
represent your mesh as table of points and remove redundant points (point = x,y,z... + int cnt=0; )
and table of lines (line = 2 * index of point from point table + bool deleted=false)
while creating table of lines for each used point increment its cnt counter
2.remove redundant lines (join border between thick lines)
find all lines that are overlapping and lie on the same line
they have the same or opposite direction
remove the shorter one and dissect the bigger one and update all tables accordingly (also point cnt !!!)
after this find all lines between points used booth more than twice
delete them ...
3.find all closed loops
something like this:
1.create list of polygons
polygon is list of point indexes
2.take any undeleted line
if found add new polygon to list and
copy its points to polygon
flag line as deleted
if not found stop
3.find line with point matching last polygon point
add the other point to polygon
flag line as deleted
repeat bullet 2 until there is no such line found
4.goto 1
4.now found polygon with the biggest bounding box
this polygon is the outer perimeter
so delete it
also you can draw it by different color for debugging purposes
5.now sum the rest
all remaining polygons are the holes
so triangulate them
and sum all triangle areas by basic math formula ...
also you can draw them by other different color for debugging purposes
This is not a straightforward problem, as the complete geometry needs to be computed incrementally, using some intersection points and/or chamfering/trimming rules.
I imagine two approaches:
1) build yourself a toolbox of the required geometric operations (using analytic geometry), among which segment/segment intersection and probably a few others (which will map to the truss design rules); using this toolbox, construct all required polygon vertices "by hand", based on the picture; lastly, compute the area of the polygonal holes with the general formula: http://en.wikipedia.org/wiki/Polygon#Area_and_centroid.
2) use a ready-made polygon manipulation library like Clipper (http://www.angusj.com/delphi/clipper.php), which will allow you to draw the logs without much care about the trimmings at endpoints (you will perform a union of rectangles and get a polygon with holes).
After my understanding of your question, the first approach is better.
UPDATE:
If what you have is a set of polygons corresponding to every log, the answer is different:
If you only care about the total area of the voids, compute the area of the outer outline and deduce the areas of every log.
And if you need the areas of individual holes, then use the second approach: perform the union of the polygons and query for the holes.
What is the best method to detect whether the red rectangle overlaps the black polygon? Please refer to this image:
There are four cases.
Rect is outside of Poly
Rect intersects Poly
Rect is inside of Poly
Poly is inside of Rect
First: check an arbitrary point in your Rect against the Poly (see Point in Polygon). If it's inside you are done, because it's either case 3 or 2.
If it's outside case 3 is ruled out.
Second: check an arbitrary point of your Poly against the Rect to validate/rule out case 4.
Third: check the lines of your Rect against the Poly for intersection to validate/rule out case 2.
This should also work for Polygon vs. Polygon (convex and concave) but this way it's more readable.
If your polygon is not convex, you can use tessellation to subdivide it into convex subparts. Since you are looking for methods to detect a possible collision, I think you could have a look at the GJK algorithm too. Even if you do not need something that powerful (it provides information on the minimum distance between two convex shapes and the associated witness points), it could prove to be useful if you decide to handle more different convex shapes.
Christer Ericson made a nice Powerpoint presentation if you want to know more about this algorithm. You could also take a look at his book, Real-Time Collision Detection, which is both complete and accessible for anyone discovering collision detection algorithms.
If you know for a fact that the red rectangle is always axis-aligned and that the black region consists of several axis-aligned rectangles (I'm not sure if this is just a coincidence or if it's inherent to the problem), then you can use the rectangle-on-rectangle intersection algorithm to very efficiently compute whether the two shapes overlap and, if so, where they overlap.
If you use axis-aligned rectangles and polygons consist of rectangles only, templatetypedef's answer is what you need.
If you use arbitrary polygons, it's a much more complex problem.
First, you need to subdivide polygons into convex parts, then perform collision detection using, for example, the SAT algorithm
Simply to find whether there is an intersection, I think you may be able to combine two algorithms.
1) The ray casting algorithm. Using the vertices of each polygon, determine if one of the vertices is in the other. Assuming you aren't worried about the actual intersection region, but just the existence of it. http://en.wikipedia.org/wiki/Point_in_polygon
2) Line intersection. If step 1 produces nothing, check line intersection.
I'm not certain this is 100% correct or optimal.
If you actually need to determine the region of the intersection, that is more complex, see previous SO answer:
A simple algorithm for polygon intersection
I need to compute the area of the region of overlap between two triangles in the 2D plane. Oddly, I have written up code for the triangle-circle problem, and that works quite well and robustly, but I have trouble with the triangle-triangle problem.
I already first check to see if one entirely contains the other, or if the other contains the first, as well as obtain all the edge-wise intersection points. These intersection points (up to 6, as in the star of David), combined with the triangle vertices that are contained within the other triangle, are the vertices of the intersection region. These points must form a convex polygon.
The solution I seek is the answer to either of these questions:
Given a set of points known to all lie on the convex hull of the point set, compute the area of the convex hull. Note that they are in random order.
Given a set of half-planes, determine the intersecting area. This is equivalent to describing both triangles as the intersection of three half-planes, and computing the solution as the direct intersection of this description.
I have considered for question 1 simply adding up all areas of all possible triangles, and then dividing by the multiplicity in counting, but that seems dumb, and I'm not sure if it is correct. I feel like there is some kind of sweep-line algorithm that would do the trick. However, the solution must also be relatively numerically robust.
I simply have no idea how to solve question 2, but a general answer would be very useful, and providing code would make my day. This would allow for direct computation of intersection areas of convex polygons instead of having to perform a triangle decomposition on them.
Edit: I am aware of this article which describes the general case for finding the intersection polygon of two convex polygons. It seems rather involved for just triangles, and furthermore, I don't really need the resulting polygon itself. So maybe this question is just asked in laziness at this point.
Question 1: why are the points in a random order? If they are, you have to order them so that connecting consecutive points with straight lines yields a convex polygon. How to order them -- for example, by running a convex hull algorithm (though there are probably also simpler methods). Once you have ordered them, compute the area as described here.
--
Question 2 is simpler. Half-plane is defined by a single line having an implicit equation a*x+b*y+c=0 ; all points (x, y) for which a*x+b*y+c <= 0 (note the inequality) are "behind" the half-plane. Now, you need at least three planes so that the intersection of their negative half-spaces is closed (this is necessary, but not sufficient condition). If the intersection is closed, it will be a convex polygon.
I suggest that you maintain a linked list of vertices. The algorithm is initialized with THREE lines. Compute the three points (in general case) where the lines intersect; these are the starting vertices of your region (triangle). You must also check that each vertex is "behind" the half-plane defined by the line going through the other two vertices; this guarantees that the intersection actually IS a closed region.
These three vertices define also the the three edges of a triangle. When you intersect by a new half-plane, simply check for the intersection between the line defining the half-plane and each of the edges of the current region; in general you will get two intersection points, but you must watch out for degenerate cases where the line goes through a vertex of the region. (You can also end up with an empty set!)
The new intersection vertices define a line that splits the current region in TWO regions. Again, use orientation of the new half-plane to decide which of the two new regions to assign to the new "current region", and which one to discard.
The points in the list defining the edges of the current region will be correctly ordered so you can apply the formula in the above link to compute its area.
If this description is not detailed/understandable, the next-best advice I can give you is that you invest in a book on computational geometry and linear algebra.