Compute time to collision of two moving bounding boxes - geometry

Given two 2-dimensional bounding boxes. Each bounding box have a different pose and velocity.
Assume the velocity of both objects stay constant, I am interested in the time point when they collide, if such a time point exists.

Shrink one of the boxes to a point and that the same time inflate the other accordingly. The shape that you obtain is the so-called Minkowski sum of the two boxes. It will be an octagon.
Then consider the difference of the speeds, which gives you a relative displacement vector. Now the problem reduces to finding the intersection between the half-line from the point and the octagon, which is relatively easy.

Related

How to calculate what percentage of a pixel is within the bounds of a shape

I have a 2d grid where pixel centers are at the intersection of two half-grid lines, as shown below.
I also have a shape that is drawn on this grid. In my case the shape is a glyph, and is described by segments. Each segment has a start point, end point and a number of off-curve points. These segments can be quadratic curves or lines. What's important is that I can know the points and functions that make up the outline of the shape.
The rule for deciding which pixels should be turned on is simple: if the center of the pixel falls within the shape outline, turn that pixel on. The following image shows an example of applying this rule.
Now the problem I'm facing has to do with anti aliasing. What I'd like to do is to calculate what percentage of the area of a given pixel falls within the outline. As an example, in the image above, I've drawn a red square around a pixel that would be about 15% inside the shape.
The purpose of this would be so that I can then turn that pixel on only by 15% and thus get some cleaner edges for the final raster image.
While I was able to find algorithms for determining if a given point falls within a polygon (ray casting), I wasn't able to find anything about this type of problem.
Can someone can point me toward some algorithms to achieve this? Also let me know if I'm going about this problem in the wrong way!
This sounds like an X, Y problem.
You are asking for a way to calculate the perecentage of pixel coverage, but based on your question, it sounds that what you want to do is anti alias a polygon.
If you are working only with single color 2D shapes (i.e red, blue, magenta... squares, lines, curves...) A very simple solution is to create your image and blur the result afterwards.
This will automatically give you a smooth outline and is simple to implement in many languages.

Determine if square cell is inside polygon

For instance, I want the grid cells (squares) inside or partially inside polygon #14 to be associated with #14. Is there an algorithm that will compute if a square is inside a polygon efficiently?
I have the coordinates of the edges that make up the polygon.
If I get it right, this is an implementation of Fortune's algorithm in JavaScript, that takes a set of 2-d points (called sites) and returns a structure containing data for a Voronoi diagram computed for this points. It returns polygons in a list called cells. It seems to use Euclidean distance as measurement. If it's true we know that polygons are always convex (see Formal definition section in Voronoi wiki page).
Now, these are options to solve this problem (hard to simple):
1. Polygon Clipping:
Form a polygon for the square.
Find its intersection with all cells.
Calculate area of this intersections.
Find the largest intersection.
2- Point in Polygon:
You also can simply find the cell that center of the square lies inside it. Ray casting is a robust PIP algorithm. Although there's a simpler approach for convex polygons (see Convex Polygons section here).
3. Distance Between Points:
I if you know the site associated to each cell then you just need to calculate distance between center of square to all sites. Regardless of what distance measurement you use to compute the Voronoi, the center point of square lie inside the cell that distance of it's associated site is minimum, since this is actually the idea for partitioning the plane in a Voronoi diagram.
Exceptions:
First approach is computationally expensive but most accurate. Second and third options work fine in most cases, however, there are exceptions that they fail to decide correctly:
Second and third are pretty much alike, but the down side of PIP is cases where point lies on edges of the polygon that cost you more overhead to detect.

fast calculation of the intersection area of a triangle and the unit square

In my current project I need to calculate the intersection area of triangles and the unit squares in an infinite grid.
For every triangle (given by three pairs of floating point numbers) I need to know the area (in the interval (0,1]) it has in common with every square it intersects.
Right now I convert both (the triangle and the square) to polygons and use Sutherland-Hodgman polygon clipping to calculate the intersection polygon, which I then use to calculate its area.
This approach now shows to be a performance bottleneck in my application. I guess a more specialized (analytical) algorithm would be much faster. Is there a standard solution for this problem, or do you have any idea? I only need the areas, not the shape of the intersections.
Your polygon are convex. There are some algorithms for convex polygons faster than general ones. I've used O'Rourke algorithm with success (code from his book here, I believe that good description exists). Note that some values may be precomputed for your squares.
If your polygons not always intersect, then you may at first check the fact of intersection with separating axes method.
Another option to try- Liang-Barski algorithm for clipping every triangle edge by square.
Edit: You can quickly find all intersections of triangle edges with grid using algorthm of Amanatides and Woo (example in grid traversal section here)
To process this task with hi performance , i suggest some modifications of
Vatti line sweep clipping.
http://en.wikipedia.org/wiki/Vatti_clipping_algorithm
Stepping from minimal Y vertex of your Triangle make such steps:
sort vertexes by Y coordinate
step Y higher to MIN(nextVertex.Y, nextGridBottom)
Calculate points of intersection of grid with edges.
Collect current trapezoid
repeat from step2 until vertex with highest Y coordinate.
Split trapezoids by X coordinate if required.
here is example of Trapezoidalization in X direction
http://www.personal.kent.edu/~rmuhamma/Compgeometry/MyCG/PolyPart/polyPartition.htm
It illustrate main idea of line sweep algorithm. Good luck.
You are not mentioning what precision you are looking for. In case you are looking for a analytical method, disregard this answer, but if you just want to do antialiasing I suggest a scanline edge-flag algorithm by Kiia Kallio. I have used it a few times and it is quite fast and can be set up for very high precision. I have a java implementation if you are interested.
You can take advantage of the regular pattern of squares.
I'm assuming the reason this is a bottleneck is because you have to wait while your algorithm finds all squares intersecting any of the triangles and computes all the areas of intersection. So we'll compute all the areas, but in batches for each triangle in order to get the most information from the fewest calculations.
First, as explained by others, for each edge of the triangle, you can find the sequence of squares that edge passes through, as well as the points at which it crosses each vertical or horizontal edge of a square.
Do this for all three sides, keeping a list of all the squares you encounter, but keep only one copy of each square. It may be useful to store the squares in multiple lists, so that all squares on a given row are all kept in the same list.
When you've found all squares the triangle's edges pass through, if two of those squares were on the same row, any squares between those two that are not in the list are completely inside the triangle, so 100% of each of those squares is covered.
For the other squares, the calculation of area can depend on how many vertices of the triangle are in the square (0, 1, 2, or 3) and where the edges of the triangle intersect the sides of the square. You can summarize all the cases in a few pencil-and-paper drawings, and come up with calculations for each one. For example, when an edge of triangle crosses two sides of the square, with one corner of the square on the "outside" side of the edge, that corner is one angle of a small triangle "cut off" by that edge of the larger triangle; use the points of intersection on the square's sides to compute the area of the small triangle and deduct it from the area of the square. If two points instead of one are "outside", you have a trapezoid whose two base lengths are found from the points of intersection, and whose height is the width of the square; deduct its area from the square. If three points are outside, deduct the entire area of the square and then add the area of the small triangle.
One vertex of the large triangle inside the square, three corners of the square outside that angle: draw a line from the remaining corner to the triangle's vertex, so you have two small triangles, deduct the entire square and add those triangles' areas. Two corners of the square outside the angle, draw lines to the vertex to get three small triangles, etc.
I'm phrasing this so that you always assume you start with the entire area of the square and reduce the area by some amount depending on how the edge of the triangle intersects the square. That way, in the case where the edges of the triangle intersect the square more than twice--such as one edge cuts across one corner of the square and another edge cuts across a different corner, you can just deduct the area cut off by the first edge, then deduct the area cut off by the second edge.
This will be a considerable number of special cases, though you can take advantage of symmetry; for example, you don't have to write the complete calculation for "cut off a triangle in one corner" four times.
You'll write a lot more code than if you just took someone's convex-polygon library off the shelf, and you will want to test the living daylights out of it to make sure you didn't forget to code any cases, but once you get it working, it shouldn't take much more effort to make it reasonably fast.

largest empty sphere or rectangle

In N (~ 500) dimensions, I wish to find out the largest sphere or rectangle such that the sphere/rectangle does not contain already existing points. The entire set of points is bounded in an axis-aligned rectangular box (lower and upper bounds on the values).
Is there any known polynomial time method/code that I can use to solve my problem?
The two well known algorithms: i) the largest empty rectangle within a rectangle (http://www.cs.princeton.edu/~chazelle/pubs/ComputLargestEmptyRectangle.pdf) and, ii) finding largest empty circle within location constraints (http://www.cs.dartmouth.edu/reports/TR86-130.pdf) do not work.
Although the complexity of above algorithms is N log N or N^2 log N, where N is the number of already existing points, the complexity is also a linear function of the number of vertices of the convex hull or the bounding polygon. A rectangle in 500 dimensions will have 2^500 corners which makes the above techniques infeasible.
Ideally, I am looking for a method (it does not have to be exact) that can determine the largest cirle/rectangle in polynomial time in N (number of points) and D (the dimension).
Thank you.
One possible heuristic solution is to restrict the large rectangle so that it's axis-aligned. In this case, a rectangle can be bounded by at most 2 * d points, where each point represents a bounding min or max to one or more dimensions. It can be then be determined if a point is inside that rectangle in only O(d).
A heuristic method to make use of this is to pick 2 points, and use those to form an initial bounding box, then randomly add points. If the point is inside the box, shrink or split the box. If the point is outside of the box, try to make the box bigger. A single pass should take O(d * N) if the box is shrunk instead of split.
The quality perhaps can be improved a bit by ensuring that no point is within the bounding box formed by the two points. It might be ideal to find all pairs of points such that no point is within the bounding box, as when converted to a graph, they should help with expanding the solution in a less random way. Dynamic programming likely leads to an algorithm that is better than O(d*N^3) perhaps O(d*N^2) or better.

How to find line segments intersecting a 2D viewport

In an infinite 2D space there are a set of lines, each line having a start and end point, and a time of creation: Line(p0, p1, t).
I want to find the lines that should be rendered in a top-down view of this 2D space (higher values of t show up closer to the viewport, not that it should be relevant.)
The intuitive answer is "check if either point is within the viewport coordinates," but this falls down when the points are further apart than the viewport area covers.
The other idea I had was using something like geohash, this would limit precision i.e. maximum zoom level of the viewport. The idea is enumerating the hashes of the cells intersected and storing them. This way querying is a matter of asking the right question.
Are there any ideal solutions? Has this been solved before?
I think you need to check two conditions: one that the rectangle of viewport overlaps the rectangle with corners (p0,p1) and the second that some corners of viewport rectangle are on the different sides of the whole line which contains line segment (p0,p1).
The task of finding rectangle overlap can be solved very effectively for very large number of rectangles using R-trees (http://en.wikipedia.org/wiki/R-tree).
The second task can be reduced to checking signs of the cross product of (p1-p0) x (corner_coordinate-p0)
(all three quantities taken as 3-d vectors with third coordinate equal to zero, the result will be vector along the perpendicular direction). There should be corners with the opposite sign of this cross product.

Resources