Function that tests whether a 3D point is inside a mesh. #2
Conversation
There was a problem hiding this comment.
I made some minor comments. I started digging into the algorithm, but I think it probably does not make sense to scrutinize it too intensely at the moment. The initial tests provide proof that it fundamentally works (although a couple more nuanced tests would be a good idea). The only change I would advise making immediately is renaming from InteriorPointTest to something without Test in the name, perhaps just Interior or maybe MeshInterior.
I started talking with ChatGPT to revive my attempt to use CGAL to do this sort of test. In a nutshell: with AABB trees and BVHs. I wish I could find the time to get it working in CGAL with these structures and then benchmark the performance compared to this Z-slice-based implementation, but realistically probably not any time soon, unless we find a critical bug in this algorithm and decide we really need it more urgently.
That is: it will only consider one direction of the ray instead of looking for infinite line interesection. This could be added separately.
Based on quickly selecting the triangles that intersect with the Z-plane of the point, then performing ray-casting among those to know how many intersection we have. Should be okish with performance. I reused to trick of shifting the Z positions by a small fixed quantity separately for the points and the triangles. Does not work perfectly yet. I think I forgot to deal with cases where the intersection lies exactly on an edge, which cannot be avoided. This is why the JUnit test fails in one case.
Still not the core problem...
The hollow cube test does not pass, despite of the assertion of inside being correct. When we extrude the inside hollow cube, the mesh interpolates triangles and yield triangles that have a 45º angle. Because we validate the interior point test against a predicate testing whether a point is inside the intervals that were used to create the image on which we created the mesh, there are small spaces near the inside limit where a point can be correctly inside the mesh and also inside the extruded cube, making this test fail.
Test the situation where the ray casting algorithm will just cross an edge between two triangles with opposite normals. It makes the test fail in this case, because the ray casting treats the intersection with the 2 triangles as one. They should be treated as two if their normals projected on the ray are opposed.
Using the normals to determine whether we cross the mesh border or not, when we have identical X intersections. We don't have to deal with cases where we cross a vertex, because we don't: in this algorithm, the vertices Z position is shifted to odd intervals, while the points Z position is shifted to even intervals.
Z is enough to avoid vertex intersection.
And fix compile errors after rebasing on master.
tinevez
force-pushed
the
interior-test
branch
from
d06b87b to
98081b4
Compare
|
Done! |
Because we use the perturbation in Z trick, it is not strictly an interior test.
It tries to have decent performance, without using AABB meshes, by using an fast face retrieval:
This algo can deal with border cases where the ray crosses an edge between two triangles that may or may not correspond to crossing the mesh.
Its absolute performance was not judged as fantastic by Ella with 0.2ms / point :) but we don't know yet how other implementations fare.
https://imagesc.zulipchat.com/#narrow/stream/391996-.5B2023-06.5D-scenery.2Bsciview-hackathon-dresden/topic/Half-edge.20data.20structure.20in.20Java