I need an algorithm for splitting a (convex) polygon (let's call it base polygon). The polygon should be splitted into several smaller polygons by another polygon's edges (let's call this one the splitting polygon).
I know there exist algorithms for clipping a polygon (f.e. the Sutherland-Hodgman algorithm), but these algorithms discard the vertices that are lying outside of the splitting polygon instead of creating new polygons with them. I don't want to clip a polygon, i want to split it into several small parts.
I know the answer seems quite obvious because I would just have to extend the existing algorithms.
The problem is that I can't figure out a nice and performant way of doing this.
Are there existing algorithms that describe how to best split a polygon in a performant way?
There has to be a simple solution for this problem that I can't figure out at the moment.
You can see this problem as that of finding the intersection of the subject polygon and the complement of the window polygon. So you can use the standard Surtherland-Hodgman algorithm for that purpose, taking two precautions:
swap the roles of the subject and the window (actually your window is not convex as you consider its complement, only the subject is convex),
embed the window polygon in a large bounding box that covers both polygons, and consider the box as a polygon with a hole.
Example: the subject polygon is the rectangle and the window is the pentagon. Form the green polygon (larger rectangle with a hole) and clip it inside the rectangular (convex) window. The result of the clipping is in blue.
With some extra care, it should be possible to do without the large bounding box.
Related
I have a kind of cutting problem. There is an irregular polygon that doesn't have any holes and a list of standard sized of rectangular tiles and their values.
I want an efficient algorithm to find the single best valued tile that fit in this polygon; or an algorithm that just says if a single tile can fit inside the polygon. And it should run in deterministic time for irregular polygons with less than 100 vertices.
Please consider that you can rotate the polygon and tiles.
Answers/hints for both convex and non-convex polygons are appreciated.
Disclaimer: I've never read any literature on this, so there might be a better way of doing this. This solution is just what I've thought about after having read your question.
A rectangle has two important measurements - it's height and it's width
now if we start with a polygon and a rectangle:
1: go around the perimeter of the polygon and take note of all the places the height of the rectangle will fit in the polygon (you can store this as a polygon*):
2: go around the perimeter of the new polygon you just made and take note of all the places the width of the rectangle will fit in the polygon (again, you can store this as a polygon):
3: the rectangle should fit within this new polygon (just be careful that you position the rectangle inside the polygon correctly, as this is a polygon - not a rectangle. If you align the top left node of the rectangle with the top left node of this new polygon, you should be ok)
4: if no area can be found that the rectangle will fit in, rotate the polygon by a couple of degrees, and try again.
*Note: in some polygons, you will get more than one place a rectangle can be fitted:
After many hopeless searches, I think there isn't any specific algorithm for this problem. Until, I found this old paper about polygon containment problem.That mentioned article, present a really good algorithm to consider if a polygon with n points can fit a polygon with m points or not. The algorithm is of O(n^3 m^3(n+m)log(n+m)) in general for two transportable and rotatable 2D polygon.
I hope it can help you, if you are searching for such an irregular algorithm in computational geometry.
This might help. It comes with the source code written Java
http://cgm.cs.mcgill.ca/~athens/cs507/Projects/2003/DanielSud/
I am tyring to cover a simple concave polygon with a minimum rectangles. My rectangles can be any length, but they have maximum widths, and the polygon will never have an acute angle.
I thought about trying to decompose my concave polygon into triangles that produce a set of minimumally overlapping rectangles minimally bounding each triangle and then merging those rectangles into larger ones. However, I don't think this will work for small notches in the edges of the polygon. The triangles created by the reflex vertices on those notches will create the wrong rectangles. I am looking for rectangles that will span/ignore notches.
I don't really know anything about computational geometry, so I'm not really sure on how to begin asking the question.
I found other posts that were similar, but not what I need:
split polygon into minimum amount of rectangles and triangles
Covering an arbitrary polygon with minimum number of squares
Find $k$ rectangles so that they cover the maximum number of points
Algorithm for finding the fewest rectangles to cover a set of rectangles
Some examples: Black is the input. Red is the acceptable output.
Another exmaple: The second output is prefered. However, generating both outputs and using another factor to determine preference is probably necessary and not the responsibility of this algorithm.
Polygons that mimic curves are extremely rare. In this scenario much of the area of the rectangles is wasted. However, this is acceptable because each rectangle obeys the max width constraint.
Also, I found this article to be close to what I need:
Covering with rectangular pieces by Paul Iacob, Daniela Marinescu, and Cristina Luca
Maybe a better question is "How can I identify rectangular-like portions of a concave polygon?"
Here is an image showing the desired implementation:
The green is the actual material usage. The red rectangles are the layouts. The blue is the MBR of the entire polygon. I am thinking I should try to get little MBRs and fill them in. The 2-3 green rectangles in the upper left corner that terminate into the middle of the polygon are expensive. That is what I want to minimize. The green rectangles have a min and max width and height, but I can use as many rows and columns necessary to cover a region. Again, I must minimize the number of rectangles that do not span across the input. I can also modify the shape of the green rectangle to fit in small places that is also very expensive. In other words, getting as many rectangles as possible to span as much as possible is ideal.
Maybe I should simply be trying to identify rectangular regions like this:
Or, perhaps a better approach would be using largest-inscribed rectangles instead of MBRs. I could continually cut my polygon down using rectangles until I am left with regions were the largest-inscribed rectangle is not sharing an edge with the original polygon. The remaining regions would have to be handled with a heuristic approach.
I've been working with the engineering and manufacturing departments at my company to bring more clarificaiton to this problem. I am still waiting to confirm, but I am now thinking an algorithm that would return sets of largest inscribed rectangles would work. While it does not completely cover the shape, it would give preference to the orthognal regions while leaving the non-orthogonal regions to some heuristics. The only trick is to maxamize those orthogonal regions.
I posted some days ago this question: How to intersect multiple polygons?. Now I implemented a sweep line algorithm as recommended (concrete the one from Martinez, Rueda and Feito).
The result is a set of polygons that do not overlap. But these polygons can contain each other (holes) or touch the boundaries (being a hole or an island polygon).
A picture of what I mean:
I think this should cover all the special cases; intersections are handled by the sweep line algorithm.
Now I need the area of the polygons (marked gray). My first idea was to add polygon by polygon and to check if they contain each other and use some intelligent selection mechanism to only select the needed polygons. But this generates some O(n^2) algorithm: For each polygon to process, every edge has to be compared to every edge that is already processed.
Not that good. Can you give me a hint how to calculate the total area?
The standard vertex order is counterclockwise for polygons and clockwise for holes. If you store your data using this convention, just compute the area with the standard polygon area calculation method. Areas of the holes will be negative.
If you have them in some other order, then you have a problem. Better fix it now.
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 was wondering if anybody could point me to the best algorithm/heuristic which will fit my particular polygon packing problem. I am given a single polygon as a boundary (convex or concave may also contain holes) and a single "fill" polygon (may also be convex or concave, does not contain holes) and I need to fill the boundary polygon with a specified number of fill polygons. (I'm working in 2D).
Many of the polygon packing heuristics I've found assume that the boundary and/or filling polygons will be rectangular and also that the filling polygons will be of different sizes. In my case, the filling polygons may be non-rectangular, but all will be exactly the same.
Maybe this is a particular type of packing problem? If somebody has a definition for this type of polygon packing I'll gladly google away, but so far I've not found anything which is similar enough to be of great use.
Thanks.
The question you ask is very hard. To put this in perspective, the (much) simpler case where you're packing the interior of your bounded polygon with non-overlapping disks is already hard, and disks are the simplest possible "packing shape" (with any other shape you have to consider orientation as well as size and center location).
In fact, I think it's an open problem in computational geometry to determine for an arbitrary integer N and arbitrary bounded polygonal region (in the Euclidean plane), what is the "optimal" (in the sense of covering the greatest percentage of the polygon interior) packing of N inscribed non-overlapping disks, where you are free to choose the radius and center location of each disk. I'm sure the "best" answer is known for certain special polygonal shapes (like rectangles, circles, and triangles), but for arbitrary shapes your best "heuristic" is probably:
Start your shape counter at N.
Add the largest "packing shape" you can fit completely inside the polygonal boundary without overlapping any other packing shapes.
Decrement your shape counter.
If your shape counter is > 0, go to step 2.
I say "probably" because "largest first" isn't always the best way to pack things into a confined space. You can dig into that particular flavor of craziness by reading about the bin packing problem and knapsack problem.
EDIT: Step 2 by itself is hard. A reasonable strategy would be to pick an arbitrary point on the interior of the polygon as the center and "inflate" the disk until it touches either the boundary or another disk (or both), and then "slide" the disk while continuing to inflate it so that it remains inside the boundary without overlapping any other disks until it is "trapped" - with at least 2 points of contact with the boundary and/or other disks. But it isn't easy to formalize this "sliding process". And even if you get the sliding process right, this strategy doesn't guarantee that you'll find the biggest "inscribable disk" - your "locally maximal" disk could be trapped in a "lobe" of the interior which is connected by a narrow "neck" of free space to a larger "lobe" where a larger disk would fit.
Thanks for the replies, my requirements were such that I was able to further simplify the problem by not having to deal with orientation and I then even further simplified by only really worrying about the bounding box of the fill element. With these two simplifications the problem became much easier and I used a stripe like filling algorithm in conjunction with a spatial hash grid (since there were existing elements I was not allowed to fill over).
With this approach I simply divided the fill area into stripes and created a spatial hash grid to register existing elements within the fill area. I created a second spatial hash grid to register the fill area (since my stripes were not guaranteed to be within the bounding area, this made checking if my fill element was in the fill area a little faster since I could just query the grid and if all grids where my fill element were to be placed, were full, I knew the fill element was inside the fill area). After that, I iterated over each stripe and placed a fill element where the hash grids would allow. This is certainly not an optimal solution, but it ended up being all that was required for my particular situation and pretty fast as well. I found the required information about creating a spatial hash grid from here. I got the idea for filling by stripes from this article.
This type of problem is very complex to solve geometrically.
If you can accept a good solution instead of the 100% optimal
solution then you can to solve it with a raster algorithm.
You draw (rasterize) the boundary polygon into one in-memory
image and the fill polygon into another in-memory image.
You can then more easily search for a place where the fill polygon will
fit in the boundary polygon by overlaying the two images with
various (X, Y) offsets for the fill polygon and checking
the pixel values.
When you find a place that the fill polygon fits,
you clear the pixels in the boundary polygon and repeat
until there are no more places where the fill polygon fits.
The keywords to google search for are: rasterization, overlay, algorithm
If your fill polygon is the shape of a jigsaw piece, many algorithms will miss the interlocking alignment. (I don't know what to suggest in that case)
One approach to the general problem that works well when the boundary is much larger than
the fill pieces is to tile an infinite plane with the pieces in the best way you can, and then look for the optimum alignment of the boundary on this plane.