I have two 3D polygonal chains and I want to know if they intersect or not. This problem is known as the Polygonal Chain Intersection. Good algorithms exists for the 2D case, but I have not seen any for the 3D case
Anybody can help with this?
Ok, maybe this is a stupid algorithm, but why don't you pick some plane (in general position, or one of the coordinate planes), project orthogonally the two 3D chains onto the plane and solve the 2D problem using one of these efficient algorithms, which will allow you to locate all points of intersection between the projections and all pairs of segments from the two 3D chains, whose projections intersect at the intersection points. Then from each intersection 2D point, draw the line through that point, perpendicular to the plane and check where this line intersects each of the two 3D segments, one from the first 3D chain, the other from the second, whose projections intersect at the 2D intersection point. If the resulting points are different, the 2D projected intersection point is not a true 3D intersection point. Else, you get an intersection point for the 3D chains.
Related
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'm looking for a way to comput the intersection points of a line with a polygonal mesh in a 3D space.
I couldn't find an algorithm that does that.
Is there a simple algorithm (pseudo code) that returns the intersection points?
Just test the intersection of the line with each face of the mesh. If your mesh has a large number of faces, you may want to use something like an octree or kd-tree to speed this process up.
My problem is to find if a generic (convex or concave) polygon and a rectangular polygon in 3D space has a not-null intersection. Each polygon is defined by the set of the ordinated contour points (if point p1 is after/before point p2 the edge p1-p2 exists).
It is easy to find the intersection line of the two plane of the polygons so the problem is finding the intersections of a line and the finite polygons and if the resulting intersections have a portion in common. I found algorithms for the intersection of a line and a convex polygon but I can't find anything for the general case of concave polygon.
Any suggestion?
Thank you
find the intersection point of the plane-intersection line with every edge of both figures. From there its s straightforward problem of looking at the ordering of the points on the line to check for any overlap.
Of course the special case where they are coplanar is a whole other problem..
There are usually no fast solutions for concave polygon intersection / containment/ etc queries.
The general solution is always to triangulate the polygon into a series of convex triangles, then run your intersection test with those triangles.
If you can rely on the polygon to be planar, you can first intersect the line with the plane and then transform the intersection point into the coordinate system of the plane.
Assuming you have also transformed all the vertices of the polygon, the problem is now to decide whether the 2D intersection point is within a 2D polygon.
What is a fast algorithm for determining whether or not a point is inside a 3D mesh? For simplicity you can assume the mesh is all triangles and has no holes.
What I know so far is that one popular way of determining whether or not a ray has crossed a mesh is to count the number of ray/triangle intersections. It has to be fast because I am using it for a haptic medical simulation. So I cannot test all of the triangles for ray intersection. I need some kind of hashing or tree data structure to store the triangles in to help determine which triangle are relevant.
Also, I know that if I have any arbitrary 2D projection of the vertices, a simple point/triangle intersection test is all necessary. However, I'd still need to know which triangles are relevant and, in addition, which triangles lie in front of a the point and only test those triangles.
I solved my own problem. Basically, I take an arbitrary 2D projection (throw out one of the coordinates), and hash the AABBs (Axis Aligned Bounding Boxes) of the triangles to a 2D array. (A set of 3D cubes as mentioned by titus is overkill, as it only gives you a constant factor speedup.) Use the 2D array and the 2D projection of the point you are testing to get a small set of triangles, which you do a 3D ray/triangle intersection test on (see Intersections of Rays, Segments, Planes and Triangles in 3D) and count the number of triangles the ray intersection where the z-coordinate (the coordinate thrown out) is greater than the z-coordinate of the point. An even number of intersections means it is outside the mesh. An odd number of intersections means it is inside the mesh. This method is not only fast, but very easy to implement (which is exactly what I was looking for).
This is algorithm is efficient only if you have many queries to justify the time for constructing the data structure.
Divide the space into cubes of equal size (we'll figure out the size later). For each cube know which triangles has at least a point in it. Discard the cubes that don't contain anything. Do a ray casting algorithm as presented on wikipedia, but instead o testing if the line intersects each triangle, get all the cubes that intersect with the line, and then do ray casting only with the triangles in these cubes. Watch out not to test the same triangle more than one time because it is present in two cubes.
Finding the proper cube size is tricky, it shouldn't be neither to big or too small. It can only be found by trial and error.
Let's say number of cubes is c and number of triangles is t.
The mean number of triangles in a cube is t/c
k is mean number of cubes that intersect the ray
line-cube intersections + line-triangle intersection in those cubes has to be minimal
c+k*t/c=minimal => c=sqrt(t*k)
You'll have to test out values for the size of the cubes until c=sqrt(t*k) is true
A good starting guess for the size of the cube would be sqrt(mesh width)
To have some perspective, for 1M triangles you'll test on the order of 1k intersections
Ray Triangle Intersection appears to be a good algorithm when it comes to accuracy. The Wiki has some more algorithms. I am linking it here, but you might have seen this already.
Can you, perhaps improvise by, maintaining a matrix of relationship between the points and the plane to which they make the vertices? This subject appears to be a topic of investigation in the academia. Not sure how to access more discussions related to this.
I've got a bunch of overlapping triangles from a 3D model projected into a 2D plane. I need to merge each island of touching triangles into a closed, non-convex polygon.
The resultant polygons shouldn't have any holes in them (since the source data doesn't).
Many of the source triangles share (floating point identical) edges with other triangles in the source data.
What's the easiest way to do this? Performance isn't particularly important, since this will be done at design time.
Try gpc, or the General Polygon Clipper Library.
Imagine the projection onto a plane as a "view" of the model (i.e. the direction of projection is the line of sight, and the projection is what you see). In that case, the borders of the polygons you want to compute correspond to the silhouette of the model.
The silhouette, in turn, is a set of edges in the model. For each edge in the silhouette, the adjacent faces will have normals that either point away from the plane or toward the plane. You can check this be taking the dot product of the face normal with the plane normal -- look for edges whose adjacent face normals have dot products of opposite signs with the projection direction.
Once you have found all the silhouette edges you can join them together into the boundaries of the desired polygons.
Generally, you can find more about silhouette detection and extraction by googling terms like mesh silouette finding detection. Maybe a good place to start is here.
I've also found this[1] approach, which I will be trying next.
[1] 2d outline algorithm for projected 3D mesh