Making a list of outermost circles on a plane - algorithm

I have a big rectangle filled with circles. The circles might overlap each other, but they all have the same diameter. I need to find the "borderline" circles. If there are gaps between these borderline circles - and the gap is bigger than a circle diameter - the one inside should also be included.
Here are some examples:
What I need to do in is to make these outer circles immovable, so that when the inner circles move - they never exit the rectangle. How can it be made, are there any known algorithms for such a thing? I'm doing it in TypeScript, but I guess, any imperative language solution can be applied

This is perhaps too conservative but certainly won't let any disks out.
Compute a Delaunay triangulation on the centers of the circles. A high-quality library is best because the degenerate cases and floating-point tests are tricky to get right.
Using depth-first search on the planar dual, find all of the faces that are reachable from the infinite face crossing only edges longer than (or equal to? depends on whether these are closed or open disks) two times the diameter.
All of the points incident to these faces correspond to the exterior disks.

I'm not quite sure that I have the answer to your question, but I put together two quick examples using the Tinfour Delaunay Triangulation library (which is written in Java). I had to digitize your points by hand, so I didn't quite hit the center in all cases.
The first picture shows that the boundary of a Delaunay Triangulation is a convex polygon. This is easy to build, simply add the vertices (circle centers) to Tinfour's IncrementalTin class and then ask it for the bounding polygon. Pretty much any Delaunay library will support this. So you wouldn't necessarily need Tinfour.
The problem is that this may include areas that are not valid for your interior circles. I played a little with ways to introduce concavities to the bounding polygon. As you can see below, the vertices in the lower-right corner had to be lopped off entirely (if I understand what you are looking for). I then iterated over the perimeter edges and introduced concavities where the vertex opposite each exterior edge was a "guard" vertex.
The code I wrote to do this is pretty messy. But if this is what you are looking for, I'll try to get it cleaned up and post it here.

Related

how to find all triangles for surface knowing vertices

I need to find all vertices that makes my surface, but I only know vertices (keep them as array) and edges. I'm doing it in XY coordinate system. I need it for Unity3D project (so pseudocode or C# code will be very helpful), but any mathematic ideas are appreciated, too.
I made some pictures for example.
If I don't have convex angle in my example it's really easy - I choose any vertex (e.g. 0) and take two next vertex in the loop. It gaves me triangles 0-1-2, 0-2-3 and 0-3-4.
It's quite easy, too, if I have one convex angle. I don't know how to find which vertex is convex (any ideas?) but it doesn't seem very complicated. Then I take him and make the same algorithm as above.
Unfortunatelly my idea stopped work for more complicated shapes, e.g (I always have one shape in my project, I just draw more of them to show more complex examples):
If I have shapes like this and try to use method described above, always any triangle is out of my shape.
I think that I can use for that any mathematic. My vertices are on XY coordinates, so I can count something. I can make more vertices if I need, too, so I could have:
I was trying to describe my problem as exactly how I can. I hope my english is understable.
Please, if you have any ideas - math ideas or pseudocode ideas how to make a surface for my vertices - write. If you have any single suggestion, not concrete idea - write, too. I am looking for inspiration, ideas, anything.
I'll make two assumptions:
You don't have any particular standards of one triangulation being better than another.
You want something conceptually easy.
Pick any vertex. Connect to any other vertex such that the formed line is entirely within the polygon. This means
The other vertex is not adjacent to the original
the connecting segment doesn't cross a side of the polygon.
It's possible that there is no such vertex. If so, then move to the next vertex, iterating until you find a pair you can connect. There will be at least one such pair.
When you draw that new segment, you've also divided the polygon into two polygons, each of which has fewer vertices than the original.
Recur on each of these polygons. Your stopping case (base case) on each thread is that you don't divide a triangle.

Place a marker arbitrarily inside a polygon in Google Maps

There is a lot of documentation around how to detect if a marker is within a polygon in Google Maps. However, my question is how can I arbitrarily place a marker inside a polygon (ideally as far as possible from the edges)
I tried calculating the average latitude and longitude of the polygon's points, but this obviously fails in some non-concave polygons.
I also thought about calculating the area's center of mass, but obviously the same happens.
Any ideas? I would like to avoid trial-and-error approaches, even if it works 99% of the time.
There are a few different ways you could approach this, depending on what exactly you're overall goal is.
One approach would be to construct a triangulation of the polygon and place the marker inside one of the triangles. If you're not too worried about optimality you could employ a simple heuristic, like choosing the centroid of the largest triangle, although this obviously wont necessarily give you the point furthest from the polygon edges. There are a number of algorithms for polygon triangulation: ear-clipping or constrained Delaunay triangulation are probably the way to go, and a number of good libraries exist, i.e. CGAL and Triangle.
If you are interested in finding an optimal placement it might be possible to use a skeleton based approach, using either the medial-axis or the straight skeleton of the polygon. The medial-axis is the set of curves equi-distant from the polygon edges, while the straight skeleton is a related structure. Specifically, these type of structures can be used to find points which are furthest away from the edges, check this out for a label placement application for GIS using an approach based on the straight skeleton.
Hope this helps.

Method to detect intersection between a rectangle and a polygon?

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

Efficient Packing Algorithm for Regular Polygons

I'm looking for a packing algorithm which will reduce a regular polygon into rectangles and right triangles. The algorithm should attempt to use as few such shapes as possible and should be relatively easy to implement (given the difficulty of the challenge).
If possible, the answer to this question should explain the general heuristics used in the suggested algorithm.
I think the answer is fairly simple for regular polygons.
Find an axis of symmetry, and draw a line between each vertex and its mirror. This divides the polygon into trapezoids. Each trapezoid can be turned into a rectangle and two right triangles.
It's not specifically rectangles + right triangles, but a good research point for looking into tesselating polygons is Voronoi Diagrams and Delaunay Triangulations and here and here.
In fact, if "just right triangles" is good enough, these are guaranteed to triangulate for you, and you can always split any triangle into two right triangles, if you really need those. Or you can chop off "tips" of triangles to make more right triangles and some rectangles out of the right-triangles.
You can also try ear-clipping, either by sweeping radially, if you know you have fairly regular polygons, or by "clipping the biggest convex chunk" off. Then, split each remaining triangle into two to create right triangles.
(source: eruciform.com)
You could try to make less breaks by sweeping one way and then the other to make a trapezoid and split it differently, but you then have to do a check to make sure that your sweep-line hasn't crossed another line someplace. You can always ear-clip, even with something practically fractal.
However, this sometimes creates very slim triangles. You can perform heuristics, like "take the biggest", instead of clipping continuously along the edge, but that takes more time, approaching O(n^2). Delaunay/Vornoi will do it more quickly in most cases, with less slim triangles.
You can try "cuting out" the largest rectangle that can fit in the polygon, leaving behind some leftovers. Keep repeating the cutting out of rectangles on the leftovers, until you end up with triangular pieces. Then, you can split them into two right triangles if necessary. I do not know if this will always yield solutions that will give you the least amount rectangles and right triangles.

Efficient Packing Algorithm for Irregular Polygons

I'm looking for a packing algorithm which will reduce an irregular polygon into rectangles and right triangles. The algorithm should attempt to use as few such shapes as possible and should be relatively easy to implement (given the difficulty of the challenge). It should also prefer rectangles over triangles where possible.
If possible, the answer to this question should explain the general heuristics used in the suggested algorithm.
This should run in deterministic time for irregular polygons with less than 100 vertices.
The goal is to produce a "sensible" breakdown of the irregular polygon for a layman.
The first heuristic applied to the solution will determine if the polygon is regular or irregular. In the case of a regular polygon, we will use the approach outlined in my similar post about regular polys: Efficient Packing Algorithm for Regular Polygons
alt text http://img401.imageshack.us/img401/6551/samplebj.jpg
I don't know if this would give the optimal answer, but it would at least give an answer:
Compute a Delaunay triangulation for the given polygon. There are standard algorithms to do this which will run very quickly for 100 vertices or fewer (see, for example, this library here.) Using a Delaunay triangulation should ensure that you don't have too many long, thin triangles.
Divide any non-right triangles into two right triangles by dropping an altitude from the largest angle to the opposite side.
Search for triangles that you can combine into rectangles: any two congruent right triangles (not mirror images) which share a hypotenuse. I suspect there won't be too many of these in the general case unless your irregular polygon had a lot of right angles to begin with.
I realize that's a lot of detail to fill in, but I think starting with a Delaunay triangulation is probably the way to go. Delaunay triangulations in the plane can be computed efficiently and they generally look quite "natural".
EDITED TO ADD: since we're in ad-hoc heuristicville, in addition to the greedy algorithms being discussed in other answers you should also consider some kind of divide and conquer strategy. If the shape is non-convex like your example, divide it into convex shapes by repeatedly cutting from a reflex vertex to another vertex in a way that comes as close to bisecting the reflex angle as possible. Once you've divided the shape into convex pieces, I'd consider next dividing the convex pieces into pieces with nice "bases", pieces with at least one side having two acute or right angles at its ends. If any piece doesn't have such a "base" you should be able to divide it in two along a diameter of the piece, and get two new pieces which each have a "base" (I think). This should reduce the problem to dealing with convex polygons which are kinda-sorta trapezoidal, and from there a greedy algorithm should do well. I think this algorithm will subdivide the original shape in a fairly natural way until you get to the kinda-sorta trapezoidal pieces.
I wish I had time to play with this, because it sounds like a really fun problem!
My first thought (from looking at your diagram above) would be to look for 2 adjacent right angles turning the same direction. I'm sure that won't catch every case where a rectangle will help, but from a user's point of view, it's an obvious case (square corners on the outside = this ought to be a rectangle).
Once you've found an adjacent pair of right angles, take the length of the shorter leg, and there's one rectangle. Subtract this from the polygon left to tile, and repeat. When there's no more obvious external rectangles to remove, then do your normal tiling thing (Peter's answer sounds great) on that.
Disclaimer: I'm no expert on this, and I haven't even tried it...

Resources