I have a 2D Space in which there is a convex polygon (in this case the red square) and a large number of triangles. My goal is to select the triangles
Belonging
Intersecting
Surrounding
the red square (For more clarity, the triangles I am searching for are the ones in black).
I am currently using a brute force approach by checking the listed conditions on each triangle.
Is there a more efficient algorithm or any kind of heuristic which can be applied to reduce the time complexity?
Improve efficiency with a pre-filter
As checking orthogonal coordinates are relatively easy (maybe via a quad-tree), consider first a bounding box for each object. Then easy to eliminate objects that could not possibly meet the search criteria. The remaining objects can then use a more time intensive approach.
From a comment of yours, I infer that preprocessing the triangles is not an option. So unless the triangles are known to enjoy some special property that can be exploited, you can't avoid an exhaustive comparison of all triangles to the polygon (using the separating axis theorem, among others).
Related
Is there an optimized way to get the convex hull, if I know my points are always arranged into two rectangles?
I programmed the classic convex hull algorithm (just by enumerating all points), but since I have a bunch of pairs of rectangles I was wandering if there might be a more efficient way to do it for this special case.
This is what I am talking about, to clarify:
I tried sorting the points in various ways, but I just cannot find a general rule to optimize it. Is the basic convex hull algorithm the most efficient way to do this case also?
Update
To clarify my final goal, I have ~100 rectangles already grouped into pairs of two, and thousands of points for which I have to check whether they lie within each of these convex hulls, in real time. Now that I've given some thought to it, I guess the convex hull part won't be the bottleneck in the entire operation (but there is still ~100 of them, and I am aiming for realtime 60fps processing), so I might as well use a plain ol' algorithm as #BartKiers suggested and then get back to this after profiling.
I will leave the question open for a while, perhaps someone has an idea for an optimization which might be useful anyway.
If I am right, you can enumerate all relevant configurations by noting that if the left side of a rectangle is more to the left than the left side of the other, then its two left vertices are on the convex hull.
With the same reasoning in the four cardinal directions, there are 16 distinct cases that you can hard-code.
Another way to look at it is to observe that the convex hull is the tightest bounding box of the two rectangles, with 0, 2 or 4 corners "cut off". Finding the bounding box is trivial, and you decide if a corner is to be cut when it does not belong to any of the rectangles.
You easily derive a point inclusion test from this rule. If you already have a bounding box test, it suffices to add the corner tests.
We have a 3d triangulated surface and there is a point on it. How can i find the triangle which contains the point.
We can find with testing all triangles but it is slow way. I must make the algorithm faster.
Is there any searching algorithm or is there any technique about reducing searching area?
What you need is a spatial data structure, they allow those typical queries of computational geometry. Your point is a query point for the set of triangles.
You might for example calculate a minimal bounding box for each triangle and store those into a R-tree (keep a map of which mbb is for what triangle or put those triangles as leave nodes in the R-tree) and then fast lookups of the best bounding box should give you maybe not the final result, but I think it would deliver a much reduced search area (a list of matching mbbs which result in a list of triangle candidates), where you then quickly search the exact triangle (because bounding boxes and triangles differ a bit).
You could speed up the comparison by using the bounding box of each triangle to test if the point is not contained.
Use a ´bounding sphere collision detection´ algorithm to test all triangles.
This algorithm is fast, but has false positives. On all triangles that fulfill the bounding sphere test, use your algorithm to do the final collision test.
I'm currently implementing a Bounding Volume Hierarchy for 3D-Triangles only. Sadly all explanations of BVH fall short on the part where you sort your Objects for splitting. For starters I want to aim for a balanced tree and use the median cut. This would require me to sort either the triangles or their bounding boxes(AABB) after a spatial criterion on the split axis of the current node. I'm really unsure if the maximum or minimum extend of a BB or triangle is enough for a proper separation as some triangles can be bigger. I'm also unsure if it's better to compare the bounding box or the triangle.
The second part of the problem is that sorting every step seems to be expensive. Other algorithms in computer-graphics employ presorted lists and then split those according to the splitting criterion. I don't see a way how you could efficiently compare triangles and assure that they belong to a list. Does that mean I have to sort the list every step?
You have multiple options, as you've discovered. The easiest to think about is to use the centroid of the bounding box. You could also sort by the min coordinate and separately by the max coordinate.
You can sort by each axis as a preprocess. Then each iteration is a partitioning that involves choosing which axis to split on and where to split, and storing the start/end points in that axis's sorted list.
See Ingo Wald's paper: http://www.sci.utah.edu/~wald/Publications/2007/FastBuild/download/fastbuild.pdf
The faster, lower quality approach is a linearized BVH - map each centroid to a coordinate on a space filling curve, such as a Morton code, then sort all the triangles by their Morton code, then split spans into boxes.
SAH (Surface Area Heuristic) is the most common way to evaluate where to split a set of triangles in BVH used for raytracing. You can find a good explanation on chapter 4 of PBRT book (http://www.pbrt.org). It is available for free here: http://pbrt.org/pbrt-2ed-chap4.pdf
If you have even a vague interest in raytracing, I suggest you to buy the complete book.
This is a question similar to the one here, but I figure that it would be helpful if I can recast it in a more general terms.
I have a set of polygons, these polygons can touch one another, overlap and can take on any shape. My question is, given a list of points, how to devise an efficient algorithm that find which polygons are the points located?
One of the interesting restriction of the location of the points is that, all the points are located at the edges of the polygons, if this helps.
I understand that r-trees can help, but given that I am doing a series of points, is there a more efficient algorithm instead of computing for each point one by one?
The key search term here is point location. Under that name, there are many algorithms in the computational geometry literature for various cases, from special to general. For example, this link lists various software packages, including my own. (A somewhat out-of-date list now.)
There is a significant tradeoff between speed and program complexity (and therefore implementation effort). The easiest-to-program method is to check each point against each polygon, using standard point-in-polygon code. But this could be slow depending on how many polygons you have.
More difficult is to build a point-location data structure by sweeping the plane
and finding all the edge-edge intersection points. See the this Wikipedia article to see some of your options.
I think you are bumping up against intuition about the problem (which is a quasi-analog perception) versus a computational approach which is of necessity O(n).
Given a plane, a degenerate polygon (a line), and an arbitrary set of points on the plane, do the points intersect the line or fall "above" or "below" it? I cannot think of an approach that is smaller than O(n) even for this degenerate case.
Either, each point would have to be checked for its relation to the line, or you'd have to partition the points into some tree-like structure which would require at least O(n) operations but very likely more.
If I were better at computational geometry, I might be able to say with authority that you've just restated Klee's measure problem but as it is I just have to suggest it.
If points can only fall on the edges, then you can find the polygons in O(n) by just examining the edges.
If it were otherwise, you'd have to triangulate the polygons in O(n log n) to test against the triangles in O(n).
You could also divide the space by the line extended from each segment, noting which side is inside/outside of the corresponding polygon. A point is inside a polygon if it falls on an edge or if it's on the inside part of every edge of the polygon. It's O(n) on the number of edges in the worst case, but tends to O(m) on the number of polygons on the average case.
An R-tree would help in both cases, but only if you have several points to test. Otherwise, constructing the R-tree would be more expensive than searching through the list of triangles.
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...