I need a quick algorithm to check whether a 3D Polygon (a list of 3D coordinates that are co-planar, given a list of points in counter-clockwise or clockwise order, the polygon can be convex or concave, in other words, it must be simple polygons non-intersecting itself) and a cube(given the lower-left and top-right coordinates, the cube edges align with the X/Y/Z axis) intersects.
Is there any quick way to do this? thanks.. I've google for a few pages, but not yet found something exactly the same.
Many thanks..
EDIT
Sorry, when I said 'Box', I meant 'Cube'.
A cube is defined as two corner points. lower-left and top-right (or the other pair, doesn't matter).
Check for polygon-polygon intersection between your polygon and each side of the box.
Check if any of the polygon's points are inside the box.
Here are some tests that should work
Check if 1 or more of the polygon points inside the box, but not all of them.
Check if any of the polygon's edges intersect with the edges of the box.
Check if any of the polygon's faces intersect with the faces of the box.
If any of the above hold then they intersect. All area listed as it's probably worth the trouble to test them in order as extracting the faces and calculating if they intersect may not be do able in linear time.
Related
I am trying to develop algorithm to find out not only the fact of intersection but its section or maybe its area. I found at least 6 different cases which may occur and I suppose that there are many more. That is why I am looking for universal algorithm neither try to solve each case separately. I am working with 3D box.
As a triangle and a box are convex shapes, you can use the Sutherland-Hodgman algorithm. https://en.wikipedia.org/wiki/Sutherland%E2%80%93Hodgman_algorithm
It amounts to finding the intersection of a polygon with a half-plane, and repeat this with every side of one of the shapes, against the other. Then the area is found by the shoelace formula.
In the case of an axis-aligned box, the computation is simpler.
Note that it is worth considering only the following points:
Intersection of the box and triangle;
The vertices of the triangle inside the box;
The vertices of the box inside the triangle.
(There are famous algorithms to find these points)
These points are vertices of the polygon that is the desired Intersection section, but we need to sort these points in correct order. You can do this using Graham's algorithm for finding a convex hull.
So, we have found a polygon that is box triangle intersection section.
You also can find it's area using one of the famous algorithms.
Finally I came to solution bu myself. I just intersect my box with edges of triangle to get points inside box or its faces. So I have points of my convex in the wrong order. To solve with problem I use the fact that all the points belong to one plane that is why I can find point by arithmetic mean of convex points which lies exactly inside the convex and use polar coordinates to get angle of each point. All that remains just sort the angles and we will get sorted convex.
I'm having troubles figuring out an algorithm to solve the following problem:
I want the user to be able to snap the rectangle (Could be any type of polygon) to the 4 corners of the polygon such that it's as far inside the polygon as it can be.
What I'm trying so far:
Allow user to get the object.
Find the nearest vertice on the polygon to the rectangle.
Find the furthest vertice on the rectangle to the polygon's nearest vertice.
Use a plane to find the first intersection point with the furthest rectangle's point to the polygon's point.
Shift up or down using the corresponding x/y plane based on whether the furthest point is further in the x/y coordinate.
Keep repeating the steps above until everything is inside.
As long as the enclosing polygon is convex, you can write this as a linear programming problem and then apply https://en.wikipedia.org/wiki/Simplex_algorithm to find the answer. The smaller polygon you are putting inside can be as complicated as you want.
Your inequalities are all of the conditions to make sure that each vertex of the smaller polygon is inside of the larger. You don't have to be clever here, there is no cost to extra inequalities that don't come into play.
The function to optimize is constructed as follows. Look at the interior angle of the vertex you are trying to get close to. Draw a coordinate system at that point with one axis pointing directly into the polygon (call that axis y) and the other at right angles to the first (call that axis x). You want to minimize the y value of the nearest vertex on the polygon you are putting in. (Just put the polygon you are putting in in the middle, and search for the nearest vertex. Use that.
The solution that you find will be the one that puts the two vertices as close together as possible subject to the condition that the smaller polygon has to be inside of the larger.
I'm trying to find out the 3D points of a point cloud which are inside a 3D Box. I'm able to get the points inside 3D box by the below logic, only when the 3d box is align with the axis, but on rotating the 3d box, the logic fails.
(This only applies if the box's edges are aligned with the coordinate axes.)
If the vertices are (x1,y1,z1),(x2,y1,z1),(x1,y2,z1),⋯,(x2,y2,z2), then any point (x,y,z) is inside the box if and only if
x1<x<x2
and
y1<y<y2
and
z1<z<z2
In other words, the point's coordinates are between the vertices' coordinates.
Now I got algo from https://math.stackexchange.com/questions/2909812/points-inside-a-3d-rectangle?noredirect=1&lq=1 but not able to figure out how to take the "position vectors".
Any suggestions!!
Another issue: Is there any fast way to find out all the points inside a 3D box, rather than iterating over the whole point cloud.
Any suggestion is appreciated!!!
Since you listed point-cloud-library in the question's tags, pcl::CropBox is probably what you are looking for. You basically provide the two corner points, a translation and a rotation, after that, you can extract all points inside the box.
I'll use the notation $\vec{OA}=\vec A-\vec O$ for a difference of position vectors. $O$ is one vertex, and $A,B,C$ are its three adjacent vertices.
O,A,B,C in there are vertices of cuboid. Being a parallelepiped, cube can defined by three adjacent faces, that's four points in total.
I have a list of coordinates (latitude, longitude) that define a polygon. Its edges are created by connecting two points with the arc that is the shortest path between those points.
My problem is to determine whether another point (let's call it U) lays in or out of the polygon. I've been searching web for hours looking for an algorithm that will be complete and won't have any flaws. Here's what I want my algorithm to support and what to accept (in terms of possible weaknesses):
The Earth may be treated as a perfect sphere (from what I've read it results in 0.3% precision loss that I'm fine with).
It must correctly handle polygons that cross International Date Line.
It must correctly handle polygons that span over the North Pole and South Pole.
I've decided to implement the following approach (as a modification of ray casting algorithm that works for 2D scenario).
I want to pick the point S (latitude, longitude) that is outside of the polygon.
For each pair of vertices that define a single edge, I want to calculate the great circle (let's call it G).
I want to calculate the great circle for pair of points S and U.
For each great circle defined in point 2, I want to calculate whether this great circle intersects with G. If so, I'll check if the intersection point lays on the edge of the polygon.
I will count how many intersections there are, and based on that (even/odd) I'll decide if point U is inside/outside of the polygon.
I know how to implement the calculations from points 2 to 5, but I don't have a clue how to pick a starting point S. It's not that obvious as on 2D plane, since I can't just pick a point that is to the left of the leftmost point.
Any ideas on how can I pick this point (S) and if my approach makes sense and is optimal?
Thanks for any input!
If your polygons are local, you can just take the plane tangent to the earth sphere at the point B, and then calculate the projection of the polygon vertices on that plane, so that the problem becomes reduced to a 2D one.
This method introduces a small error as you are approximating the spherical arcs with straight lines in the projection. If your polygons are small it would probably be insignificant, otherwise, you can add intermediate points along the arcs when doing the projection.
You should also take into account the polygons on the antipodes of B, but those could be discarded taking into account the polygons orientation, or checking the distance between B and some polygon vertex.
Finally, if you have to query too many points for that, you may like to pick some fixed projection planes (for instance, those forming an octahedron wrapping the sphere) and precalculate the projection of the polygons on then. You could even create some 2d indexing structure as a quadtree for every one in order to speed up the lookup.
The biggest issue is to define what we mean by 'inside the polygon'.
On a sphere, every polygon (as long as the lines are not intersecting) defines two regions of the sphere. Both regions are equally qualified to be called the inside of the polygon.
Consider a simple, 1-meter on a side, yellow square around the south pole.
You can think of the yellow area to be the inside of the square OR you can think of the square enclosing everything north of each line (the rest of the earth).
So, technically, any point on the sphere 'validly' inside the polygon.
The only way to disambiguate is to select which side of the polygon you want. For example, define the interior to always be the area to the right of each edge.
I have two 2D rectangles, defined as an origin (x,y) a size (height, width) and an angle of rotation (0-360°). I can guarantee that both rectangles are the same size.
I need to calculate the approximate area of intersection of these two rectangles.
The calculation does not need to be exact, although it can be. I will be comparing the result with other areas of intersection to determine the largest area of intersection in a set of rectangles, so it only needs to be accurate relative to other computations of the same algorithm.
I thought about using the area of the bounding box of the intersected region, but I'm having trouble getting the vertices of the intersected region because of all of the different possible cases:
I'm writing this program in Objective-C in the Cocoa framework, for what it's worth, so if anyone knows any shortcuts using NSBezierPath or something you're welcome to suggest that too.
To supplement the other answers, your problem is an instance of line clipping, a topic heavily studied in computer graphics, and for which there are many algorithms available.
If you rotate your coordinate system so that one rectangle has a horizontal edge, then the problem is exactly line clipping from there on.
You could start at the Wikipedia article on the topic, and investigate from there.
A simple algorithm that will give an approximate answer is sampling.
Divide one of your rectangles up into grids of small squares. For each intersection point, check if that point is inside the other rectangle. The number of points that lie inside the other rectangle will be a fairly good approximation to the area of the overlapping region. Increasing the density of points will increase the accuracy of the calculation, at the cost of performance.
In any case, computing the exact intersection polygon of two convex polygons is an easy task, since any convex polygon can be seen as an intersection of half-planes. "Sequential cutting" does the job.
Choose one rectangle (any) as the cutting rectangle. Iterate through the sides of the cutting rectangle, one by one. Cut the second rectangle by the line that contains the current side of the cutting rectangle and discard everything that lies in the "outer" half-plane.
Once you finish iterating through all cutting sides, what remains of the other rectangle is the result.
You can actually compute the exact area.
Make one polygon out of the two rectangles. See this question (especially this answer), or use the gpc library.
Find the area of this polygon. See here.
The shared area is
area of rectangle 1 + area of rectangle 2 - area of aggregated polygon
Take each line segment of each rectangle and see if they intersect. There will be several possibilities:
If none intersect - shared area is zero - unless all points of one are inside the other. In that case the shared area is the area of the smaller one.
a If two consecutive edges of one rectactangle intersect with a single edge of another rectangle, this forms a triangle. Compute its area.
b. If the edges are not consequtive, this forms a quadrilateral. Compute a line from two opposite corners of the quadrilateral, this makes two triangles. Compute the area of each and sum.
If two edges of one intersect with two edges of another, then you will have a quadrilateral. Compute as in 2b.
If each edge of one intersects with each edge of the other, you will have an octagon. Break it up into triangles ( e.g. draw a ray from one vertex to each other vertex to make 4 triangles )
#edit: I have a more general solution.
Check the special case in 1.
Then start with any intersecting vertex, and follow the edges from there to any other intersection point until you are back to the first intersecting vertex. This forms a convex polygon. draw a ray from the first vertex to each opposite vetex ( e.g. skip the vertex to the left and right. ) This will divide it into a bunch of triangles. compute the area for each and sum.
A brute-force-ish way:
take all points from the set of [corners of
rectangles] + [points of intersection of edges]
remove the points that are not inside or on the edge of both rectangles.
Now You have corners of intersection. Note that the intersection is convex.
sort the remaining points by angle between arbitrary point from the set, arbitrary other point, and the given point.
Now You have the points of intersection in order.
calculate area the usual way (by cross product)
.