Tetrahedra outside the domain (polyline stitching) in CGAL 3D mesh generation

[rokgm]

Issue Details

Unexpected behavior

I am generating a 3D volume mesh from a surface mesh using:

MeshCriteria(
    CGAL::parameters::facet_size(longestSurfaceEdge)
      .cell_size(longestSurfaceEdge)
      .facet_distance(facetDistance)
      .edge_min_size(0.1 * minTubeLength)
      .edge_size(longestSurfaceEdge)
      .cell_radius_edge_ratio(2)
      .facet_angle(30)
  );
using Kernel = CGAL::Exact_predicates_inexact_constructions_kernel;
using MeshDomain = CGAL::Polyhedral_mesh_domain_with_features_3<Kernel>;
MeshDomain domain(surface);
domain.add_features(<"the red polylines seen below">);

C3t3 c3t3 = CGAL::make_mesh_3<C3t3>(
    domain, criteria, CGAL::parameters::no_exude().no_perturb());

struct FacetDistance {
  FacetDistance(double insideValue, double outsideValue,
    CGAL::AABB_tree<Traits>* domainAndTubeTree,
    CGAL::AABB_tree<Traits>* crackTree)
    : insideValue(insideValue)
    , outsideValue(outsideValue)
    , domainAndTubeTree(domainAndTubeTree)
    , crackTree(crackTree)
  {
  }  double operator()(
    const Point_3& p, int dimension, const MeshDomain::Index& /*index*/) const
  {
    if (dimension != 2)
      LOG_ERROR(
        "Querying facet distance parameter with dimension not equal to 2!");    auto domainDistance = domainAndTubeTree->squared_distance(p);
    auto tubeCrackDistance = crackTree->squared_distance(p);

    bool isTubeCrack = domainDistance >= tubeCrackDistance;
  return isTubeCrack ? insideValue : outsideValue;
  }

private:
  double insideValue;
  double outsideValue;
  CGAL::AABB_tree<Traits>* domainAndTubeTree;
  CGAL::AABB_tree<Traits>* crackTree;
};

The cells circled in red are the problem. They lie outside the domain. This is caused by adding polylines.

This is the surface mesh of the domain:

In red you can see the polylines that are added. The two polylines along the crack/slit are just two polylines. Each only has two corners, at the ends of the crack/slit. Other points are added as intermediate points of the polyline.

Questions

1. How to fix the cells that are outside the domain? I can make the sampling parameter edge_min_size small enough for the cells to disappear, as you can see below. But then I have really small cells, which is not wanted. Is there a better way? They could also be removed in postprocessing.

2. How to have larger facets inside the crack/slit?

• For the crack/slit surfaces to be recognized as separate surfaces, I need to set facet_distance parameter to be small enough on the crack/slit surface patches. This is done with a sizing field which is defined above.

• This works, but causes the facets on the surface to be very small, as you can see below (on the transparent plot). I do not want such small facets on the surface as it is flat, so they are unnecessary. I tried setting facet_min_size to be larger, but then the two surfaces were no longer recognized as separate and were meshed over.

Environment

• Operating system: Linux 64 bit
• Compiler: g++ (GCC) 14.2.0
• Release or debug mode: Debug
• Specific flags used: CGAL::Sequential_tag (for CGAL::Mesh_triangulation_3<>), -DCGAL_DISABLE_GMP=1
• CGAL version: 6.1
• Boost version: 1.89.0
• Other libraries versions if used (Eigen, TBB, etc.): /

[sloriot]

Did you try to not use edge_min_size? This parameter stops the refinement of the protected edges (mean to be used when you have a problematic input, like self-intersecting mesh, not well seperated polylines...).

[rokgm]

I tried to not use edge_min_size. The result is that the two polylines are sampled extremely densely, which is not wanted.

Here is what the mesh looks like:

[sloriot]

yes but that's on purpose so that components are separated. If you want to reduce the number of elements then you can try to use this package

[rokgm]

• The approach with remeshing would probably work, but it would be too slow. Just the meshing part without the edge_min_size parameter takes a lot longer.
• Why does the sampling have to be so small to have separate components? Is it a limitation of the algorithm, because of the protecting balls placed on vertices? Balls of different features must no intersect. So a mesh like this could not be generated?

• Also regarding the question 2. Why does the small enough facet_distance for the surfaces to be treated as separate, produce such small facets?

[sloriot]

That's an unfortunate by product of Delaunay meshing. The feature protection mechanism is based on the coverage of the features using spheres. Only consecutive spheres on the polylines must intersect. You can get more detail on the theory here.