I was trying this question and found a solution :
Draw a horizontal line to the right of each point and extend it to infinity
1) Count the number of times the line intersects with polygon edges.
2) A point is inside the polygon if either count of intersections is odd or
point lies on an edge of polygon. If none of the conditions is true, then
point lies outside.
But i think there is a simple solution to this :
for(all sides in same order)
find vector product of the 3 points (given point and end points of each side)
if all products are > or < 0 : point lies inside polygon or on boundary
else outside
isn't my solution better and efficient ?
is there another simpler algorithm than this ?
The proposed algorithm using cross product check only works for convex polygons. For non-convex polygon it is quite easy to find an example where it does not work. Try any of the points c, d or e in the polygon given.
The algorithm you suggest only works for convex polygons & in fact used for calculation of the convex hull but would fail for concave which is again proved by correctness of convex hull algorithm.
Another way to use this algorithm is to divide your polygon into convex polygons and then apply the algorithm on the divided parts to see if the point is inside anyone of them
Polygon triangulation
Related
I don't know if the process has a specific name. I want to get the polygon which is created by translating a polygon. Is there an algorithm for this. For example:
.
Convex hull works for convex polygons but I want a general solution. Also I would be happy to hear if there is a way to get the polygon created by rotating.
It appears you are looking for the Minkowski sum of your polygon and the line segment describing your movement.
The CGAL library package 2D Minkowski Sums can compute them for instance.
Given the explanation you gave in comments, the straightforward approach is this:
Let v be a vector describing the linear movement
For each edge (p,q) in the polygon
construct quadrilateral (p, q, q+v, p+v)
Compute the union of all the quadrilaterals plus the original polygon
Computing polygon unions is a well-studied problem with efficient algorithms.
I have been trying to find an algorithm which computes the intersecting area of two triangles but I failed to find any. Can anybody give a clue how to write this algorithm?
I would like something like:
double getAreaOfIntersection(Vector2 p1,Vector2 p2, Vector2 p3,Vector2 p4,Vector2 p5,Vector2 p6 )
where pX represents the 2 triangles.
You could first compute the polygon which describes the intersection area by a clipping algorithm, e.g.:
Sutherland-Hodgman algorithm
Then you would compute the area of the resulting convex polygon, which is rather easy, see, e.g., here:
Area of a Convex Polygon
Determining wether or not a point lies within a given polygon is easy (and even easier for triangles since those are simple polygons). You can use the winding number algorithm (and the crossing number algorithm for simple polygons) which is implemented and well explained here.
Using this you can obtain all the vertices of your intersection polygon:
The vertices pX of a triangle that are contained in the other triangle as well
The points where the two triangles intersect (see intersection of line segments)
You will need to loop over your edges to find all the intersection points, so this should be quick enough as long as you only want to determine intersections of triangles but i would not suggest to try to find intersections of arbitrary polygons this way.
I've heard a lot of people say that programmatically finding a point in a non-convex polygon is harder than finding a point in a convex polygon. I'm having trouble wrapping my head around this. Is this true? If so, why?
So you want to check whether point P is inside a polygon or outside.
If the polygon is convex, then you can iterate over each line segment making up the polygon, and check which side of that line P lies on. P is on the inside of the polygon if it is on the right-hand side of every line segment, going clockwise.
If the polygon is concave, this algorithm doesn't work. An algorithm that works for concave polygons is to trace from P in an arbitrary direction to infinity, and count the number of times an edge of the polygon is crossed. P is inside the polygon if and only if the number of crossings is odd. This algorithm has a bunch of edge cases to consider and is generally more complicated, so it will take a lot more programmer effort to write the algorithm.
In the sense that the algorithm is more difficult to write correctly, yes, it is harder.
In the sense of computational complexity, both algorithms have Θ(N) asymptotic running time. In that sense, both problems are equally hard.
For a convex polygon, you can choose any point p inside the polygon (e.g. the center of mass of all the vertices) and then sort the vertices in a circular array according to the angle they make with p. Then, given a query point x, you can compute the angle from p to x, and search through the array and find the two neighboring vertices in the array for which the angle to x is between the angles to the two vertices. Then you compute the intersection between the line from p to x, and the edge between the two vertices. If the distance from p to the intersection point is greater than or equal to the distance from p to x, then x is inside the polygon, otherwise x is outside the polygon. This gives O(log n) time to determine is a point is inside or outside of a convex polygon. On the other hand, the best known algorithm to determine if a point is inside or outside a non-convex polygon is O(n) time. Note however you can make a hybrid algorithm depending on how much "non-convexity" you have in your polygon. You can always decompose a polygon into a union of convex polygons, by adding extra internal edges; suppose your polygon only has a few "turns" in it and you can decompose into k convex polygons where k is small. Then you can use the strategy for convex polygons to determine if a point is inside or outside in O(k log n) time. So in general, the "more convexity" you have, the faster you can determine if a point is inside the polygon.
What is the best algorithm to solve point in polygon in programming contests?
Shoot a ray(in arbitrary direction) from the point and check the number of times it has crossed the edges of polygon if it is even then the point is outside the polygon otherwise the point is inside the polygon.
If you need to do it for lots of query points, you can triangulate the polygon (actually triangulate both inside and the region between the polygon the convex containing it) so that you could do ray shooting in O(log n)
if you have a convex polygon you can use this :
http://e-maxx.ru/algo/pt_in_polygon
The problem is to find the closest features between two 2d concave polygons. The features can be vertex, edge. So result can be any combination of features. Is there any simple solution with complexity better than O(m*n)? where m, n - number of edges of polygons respectively. The polygons are coplanar.
An algorithm in O(n.log(m)) seems to exists, please see this paper, and this question.
An optimization of mine you could try: (not tested)
If your polygons are most of the time far apart enough, you can build the two convex hull and fall back on the easiest problem of finding the Hausdorff distance between two convex polygons (solution in O(n+m)). If the distance is 0, you have to fall back to the O(m.log(n)) case, but it's worth it if you are most of the time in the "convex hull" case with a positive distance.
Post-Scriptum. I just realized that in order of the postulate to work, you also need to check that the closest features from the convex hulls belongs to the original concave polygon. If not, it's easy to find a counter-example (imagine a polygon in shape of the letter C with another round just nearby: CO).
The updated postulate is then: The Hausdorff distance d between two concave polygons is the Hausdorff distance between their convex hulls, if d > 0, and both closest features are part of the original polygons.
The proof of this is left as an exercice to the reader.