I'm trying to find the number of lattice points that strictly lie inside the boundary. I know Pick's theorem is
A = i + b/2 - 1
where A = the area of the polygon, i is the number of lattice points that lie inside the polygon, and b is the number of lattice points on the perimeter of the polygon.
I can easily find the area using the Shoelace formula, but I'm not sure how to get the points on the boundary.
I'm not really sure where to look for resource on this, so I'd appreciate links too.
What a pretty question...
Since you are talking about Pick's Theorem, I will assume all of the vertices have integer coordinates.
Your question reduces to determining how many lattice points lie on the line segment from (x1, y1) to (x2, y2). Since the answer stays the same under translation by an integer, this reduces to determining how many lattice points lie on the line segment from (0, 0) to (x, y) for arbitrary x and y.
If x=0 or y=0, the answer is 1D and trivial (i.e. x+1 or y+1).
Otherwise, the answer is gcd(x,y) + 1. You prove this by showing (a) that any lattice point between (0,0) and (x,y) must be a multiple of the "least" lattice point; and (b) that any lattice point must have coordinates that are factors of (x,y).
Finally, be careful not to double-count the vertices as you walk around the polygon.
Related
I need an algorithm to quickly determine wether given 2D polygon arbitrarily translated intersects given rounded rectangle.
We're given a polygon with N vertices and dimensions of the rounded rectangle (lenghts of sides and radius of corners).
We would like to answer many question of type does the polygon with translation (dx,dy) intersect the rounded rectangle.
We're allowed to do arbitrary precomputation on the polygon.
When radius of the corners rectangle is 0, there is trivial constant time algorithm - it's enough to compute an AABB of the polygon, and then in few comparisons check if, after translation, it intersects the rectangle.
When the radius is >0 the problem seems much harder. The fact that there seems to be potentially an infinite number of "bounding rounded rectangles" suggests that there is no constant-time algorithm that can check for the intersection.
But maybe I'm missing something.
Do you know by any change any sublinear algorithm for checking if a polygon intersects a rounded rectangle?
If preprocessing of the polygon is allowed, an efficient solution is possible:
build the Minkowski sum of the polygon and rounded rectangle; this is a curvilinear polygon;
every translation of the polygon wrt the rectangle corresponds to a point wrt the Minkowski sum;
decompose the curvilinear polygon in slabs;
you can perform location of an arbitrary point in that decomposition in time O(log(N)), and this is optimal.
Below, the sum of two polygons and of a concave polygon with a disk (the loop must be excluded). This generalizes to a rounded rectangle.
To locate a point, you identify the containing slab by dichotomic search. Then inside a slab, you can identify the containing curvilinear trapezoid (delimited by line segments or circular arcs) by a second dichotomic search.
If you have few polygons, with a simple shape, you can do the preprocessing by hand. Otherwise, the Minkowski sum and slab decomposition are a little painful.
Let x1, x2, y1, y2 be the coordinates of the AABB of the rounded rectangle, with x1 < x2 and y1 < y2, and let R be the radius (of the quarter-circles).
Here is how I would handle the collision detection. Optionally, you can of course check for collision with the AABBs of both objects first, to reject early. Then, for each line in the polygon:
check for intersection with the rectangle made from the following points:
(x1, y1+R), (x1, y2-R), (x2, y1+R), (x2, y2-R)
check for intersection with the rectangle made from the following points:
(x1+R, y1), (x1+R, y2), (x2-R, y1), (x2-R, y2)
check for intersection with each of the circles in the corners, that is the circles or radius R and centers:
(x1+R, y1+R), (x1+R, y2-R), (x2-R, y1+R), (x2-R, y2-R)
If any of these three checks gives an intersection, then the polygon intersects the rounded rectangle or is completely inside. Of course, you can check whether a point of the polygon is outside the rounded rectangle using the same method (you can easily do it at the same time as the intersection checks). Because a rounded rectangle is a convex shape, this is sufficient to say that the polygon is not completely inside.
That's O(N) where N is the number of sides of your polygon. If that's the complexity you are thinking of when you say "constant-time", then I don't believe there is any kind of preprocessing that can help go below O(N) in the general case.
I am trying to find a way to determine the rectilinear polygon from a set of integer points (indicated by the red dots in the pictures below). The image below shows what I would like to achieve:
1.
I need only the minimal set of points that define the boundary of the rectilinear polygon. Most hull algorithms I can find do not satisfy the orthogonal nature of this problem, such as the gift-wrapping algorithm, which produce the following result (which is not what I want)...
2.
How can I get the set of points that defines the boundary shown in image 1.?
Updated:
Figure 1. is no longer refereed to as convex..
Following the definition from wikipedia, it is rather easy to create a fast algorithm.
Start constructing upper hull from the leftmost point (uppermost among such if there are many). Add this point to a list.
Find the next point: among all the points with both coordinates strictly greater than of the current point, choose the one with minimal x coordinate. Add this point to your list and continue from it.
Continue adding points in step 2 as long as you can.
Repeat the same from the rightmost point (uppermost among such), but going to the left. I.e. each time choose the next point with greater y, less x, and difference in x must be minimal.
Merge the two lists you got from steps 3 and 4, you got upper hull.
Do the same steps 1-5 for lower hull analogously.
Merge the upper and lower hulls found at steps 5 and 6.
In order to find the next point quickly, just sort your points by x coordinate. For example, when building the very first right-up chain, you sort by x increasing. Then iterate over all points. For each point check if its y coordinate is greater than the current value. If yes, add the point to the list and make it current.
Overall complexity would be O(N log N) for sorting.
EDIT: The description above only shows how to trace the main vertices of the hull. If you want to have a full rectilinear polygon (with line segments between consecutive points), then you have to add an additional point to your chain each time you find next point. For example, when building the right-up chain, if you find a point (x2, y2) from the current point (x1, y1), you have to add (x2, y1) and (x2, y2) to the current chain list (in this order).
I think what you want to compute is the Rectilinear Convex Hull (or Orthogonal Convex Hull) of the set of points. The rectilinear convex hull is an ortho-convex shape, that is, the intersection of the shape with any horizontal or vertical line results in an empty set, a point, or a line segment.
The vertices of the rectilinear convex hull are the set of maximal points under vector dominance. The rectilinear convex hull can then be computed in optimal O(n log n) time. A very simple algorithm is presented in Preparata's book on Computational Geometry (see the section 4.1.3).
I don't know of any standard algorithm for this but it doesn't seem too complicated to define:
Assuming each point in the grid has at least 2 neighbors (or else there's no solution)
p = a point with only two neighbors.
while p isn't null
2a. Mark p as visited
2b. next = the unmarked neighbor that has the least amount of neighbors
2c. next.parent = p
2d. p = next
done
I want to determine whether a given triangle intersects a tetrahedron. I do not want to compute the solution polygon(if it exists) itself. Is there any library/package/published practical algorithm which can be used to solve this problem directly(unlike my attempt below)?
I think as a last resort I will have to use standard polygon-polygon intersection algorithm implementations to solve this problem indirectly.
My attempt on this problem:
I thought of breaking it into the problem of polygon-polygon intersection. So for each triangular face(say T1) of the tetrahedron and the given triangle T2, I thought of doing the following:
Compute intersection(a line) between planes corresponding to each triangle, say L1.
For each triangle:
For each edge of the triangle say L2, compute point of intersection P between L1 and L2.
Test(maybe using parametric form) of L2, if the point lies on the edge L2.
If for both triangles T1 and T2, there exists at least one edge on which the intersection point P lies, then it implies that the triangles(and hence the given tetrahedron and the triangle T2) do intersect.
Create an orthonormal frame based on the triangle (origin at some vertex, axis X using the direction of some side, axis Y and Z using the direction of another side and Gram-Schmidt formulas).
Transform the coordinates of the 3 + 4 vertices to the new frame.
If all Z of the 4 tetrahedron vertices are of the same sign, there is no intersection. Otherwise, find the 3 or 4 intersection point of the edges into XY, by linear interpolation on Z.
Now you need to check for intersections between a triangle and a triangle or (convex) quadrilateral, in 2D. You can solve that by means of a standard clipping algorithm, made simple by convexity of the polygons.
As an easy optimization, note that it is useless to compute the Z of the triangle vertices (=0), and the XY of the tetrahedron vertices before you know that there is a possible intersection.
You can also speedup the polygon intersection process by first using a bounding box test.
I just found a function in CGAL library CGAL::do_intersect(Type1< Kernel > obj1,Type2< Kernel > obj2 ) for computing intersection between two geometric objects. It permits Type1 and Type2 to be Triangle_3<Kernel> and Tetrahedron_3<Kernel> respectively.
Can someone tell me any algorithm by which I can find total number of integral coordinates lying inside or on a quadrilateral. The coordinates of the quadrilateral will be given as input and you have to tell total no. of coordinates lying inside or on a quadrilateral.
For example if the points given are (5,3) (1,1) (3,4) (6,1) then answer should be 14. If you draw the quadrilateral then you will find that only 14 integral coordinates like (3,2),(5,1)..etc lies inside and on the quadrilateral.
If your quadrilateral vertices have integer coordinates, then it is possible to use Pick's theorem.
A = i + b/2 - 1
where A is area, i is the number of interior integer points, and b is the number of integer points at the borders (edges).
You can find quad area with any method (for example, see here), and find number of border points on every edge as GCD(dx, dy) (+1 term excluded to avoid counting vertices twice)
There are various points in a Grid.
Say (x,y) can be reached from (x-1,y+1) in a single unit of time. then what would be the general formula for finding distance between a point (x1,y1) to (x2,y2).
say for (0,0) to (-2,-1) i.e. coordinate can be negative too.
I could not think of general formula.
If I understand the question correctly, and diagonal movements have the same cost as "manhattan" movements, it's cheaper than the manhattan distance in most cases -- only the maximum of the x and y distances is relevant:
max(abs(x1 - x2), abs(y1 - y2))
Basically you move diagonally at cost 1 per unit until you have reached x2 or y2, then along the grid.
if (x,y) can be reached from (x-1, y+1).
Then all points reachable from (x1,y1) are (x1+k, y1-k) where k is greater than 0.