Tetrahedral mesh implementation for MeshClipper
#1771
Conversation
TetMeshClipper depends on bump to compute the tet mesh boundary.
to pass some sanity checks.
It doesn't hurt anything and it's not worth the hassle to remove.
…ture/gunney/tetmesh-clipper
gunney1
force-pushed
the
feature/gunney/tetmesh-clipper
branch
from
94f202b to
c988fd2
Compare
gunney1
requested review from
Arlie-Capps,
BradWhitlock,
bmhan12,
kennyweiss,
publixsubfan and
rhornung67
gunney1
added
Quest
| if(!geomTetsView[i].degenerate()) | ||
| { | ||
| pieceBbsView[i] = primal::compute_bounding_box<double, 3>(geomTetsView[i]); | ||
| } |
There was a problem hiding this comment.
Would it make sense to filter out degenerate tets before running the algorithm?
There was a problem hiding this comment.
Yes, that would make sense, and I originally had a SLIC_ERROR_IF there to catch it. But as a user who is given an array of tets generated elsewhere, I found it annoying to have to find and filter out the degenerate ones. The check here makes Axom more robust at a negligible cost.
| /* | ||
| * - Put surface triangles in BVH. | ||
| * - Create a bounding box and a ray for every mesh hex. The ray | ||
| * originates from the bounding box center and points away from | ||
| * the center of m_tetMeshBb. | ||
| * - Use BVH::findBoundingBoxes and BVH::findRay to get surface | ||
| * triangles near the bounding boxes and rays. | ||
| * - Loop through the hexes. | ||
| * - If hex bb is near any surface triangle bb, label the hex ON. | ||
| * - Else, the hex is either IN or OUT. It can't possibly be ON. | ||
| * Count number of surface triangles that the hex's ray intersects, | ||
| * @see intersect(const Triangle<T, 3>& tri, const Ray<T, 3>& ray) | ||
| * If the count is odd, hex is IN, if even, OUT. | ||
| */ |
There was a problem hiding this comment.
Can you please clarify this algorithm?
For each hex, it has a ray from the hex center and it's counting the intersections from the center to each triangle that it encounters within the hex bounding box and returning the parity?
Did I get that right?
Can you post some performance stats for this? Specifically, how expensive is this step (+ the query) vs. a simpler strategy of returning IN if the bounding box of a tet intersects any tets, and returning OUT otherwise? Or perhaps just checking the bounding box of each hex w/ the bounding boxes of the tets?
There was a problem hiding this comment.
You got that right. I will rewrite the comments along those lines. I plan to post performance stats for all the geometries soon. From what I've seen in my toy test configuration, this approach of counting intersections with the boundaries is not expensive. I've also seen that not identifying as many IN tets as possible will degrade fast with mesh resolution, because there will be many that are IN.
- Old version was prone to give wrong answer for concave cells. - Also, computed the tet vertex average wrong.
…ture/gunney/tetmesh-clipper
…ture/gunney/tetmesh-clipper
… into feature/gunney/tetmesh-clipper
Summary
TetMeshClipperimplementation forMeshClipper. This supports shapes defined by tetrahedral mesh, including ProE shapes.TetMeshClipper, with 2 configurations: a simple 3-tet mesh and the mesh incup.proe.This is the last of the supported geometries for
MeshClipper.