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.
Related
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.
Is there any simple algorithm like Voronoi diagram to divide any rectangular plane to triangles, eventually, using # of pre-defined points.
To be honest, I have to write a very simple fragment shader like this.
Theoretically, this Voronoii shader could be 'upgraded' by Delaunay triangulation
but wanna find the more elegant solution.
The first thing that comes to my mind is to create n random points (with specific seed) to fill a cylinder volume. The triangle points will be intersection of lines between those points and plane going through the axis of cylinder. The animation would be simply done by rotating the plane ...
I see it something like this:
So the neighboring points should be interconnected with each other. Forming tetrahedrons that fills the volume of the cylinder. So create uniform tetrahedron grid and add random noise to the points position (with specific seed).
This whole task is very similar to rendering cross section of 4D mesh see:
4D rendering techniques
As the 4D simplex is also tetrahedron. The only diference is you are in 3D and cutting by 3D plane.
You can reverse-engineer this example shadertoy.com/view/MdfBzl
like I did. Thanks to mattz.
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.
I want to do the following: I have some faces in the 3D space as polygons. I have a projection direction and a projection plane. I have a convex clipping polygon in the projection plane. I wnat to get a polygon representing the shaddow of all the faces clipped on the plane.
What I do till now: I calculate the projections of the faces as polygons in the projection plane.
I could use the Sutherland–Hodgman algorithm to clip all the singe projected polygons to clip to the desired area.
Now my question: How can I combine the projected (maybe clipped) polygons together? Do I have to use algorithms like Margalit/Knott?
The algorithm should be quite efficient because it has to run quite often. So what algorithm do you suppose?
Is it maybe possible to modify the algorithm of Sutherland–Hodgman to solve the merging problem?
I'm currently implementing this algorithm (union of n concave polygons) using Bentley–Ottmann to find all edge intersections and meanwhile keeping track of the polygon nesting level on both sides of edge segments (how many overlapping polygons each side of the line is touching). Edges that have a nesting level of 0 on one side are output to the result polygon. It's fairly tricky to get done right. An existing solution with a different algorithm design can be found at:
http://sourceforge.net/projects/polyclipping/
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.