Punching a polygonal hole into a triangulated surface

Referring to my post #38 above, I now solved the problem with “touching” cutter geometries with some tricky manipulations and “back manipulations” of the cutter polygons. What remained was the fact that a closed cutter polygon that falls completely into one single triangle of the underlying “topo surface” is still not working properly: the imprint filter generates a little triangulation inside that cutter polygon, without connecting it with the remaining surface.
My attempt of a solution was now to simply subdivide any such triangle before applying the imprint filter, by inserting another point at the centroid location of the triangle and cutting it in three new triangles.
To some degree it works, but still not really: Now I am getting holes in the topo instead:


There is definitely a chance that I am doing something wrong with the automatic “editing” of the triangulated surface, but somehow I cannot find out how this should be the case, so I attach here also the “topo surface” with the inserted extra triangles:
surface_plustri.vtp (29.3 KB)
What I am also getting during the imprint operation is a warning message:

vtkImprintFilterAtg.cxx, line 2890 vtkImprintFilterAtg (0x55611cb5a2f0): Merge tolerance <= 0.0

I cannot see the location where any “merge tolerance” would be applied! I had this message when the cutter polygons had touching points, but these are by now completely removed.
(Note: vtkImprintFilterAtg is the current version of your vtkImprintFilter, downloaded, renamed and integrated into my code - in order to avoid moving my entire software to the new VTK and ParaView versions - which I intend to do only a bit later due to lack of time.)

Additional finding: If I reduce the cutter polygons to only the one rectangle at the “bottom”, the imprinting is successful with the subdivided triangle:


Here is the reduced rectangle: ring_period2_region2_extract.vtp (16.9 KB)
Also here I am getting the warning about “Merge tolerance <= 0.0”

One more success: It turned out that the sense of rotation of the “bottom” polygon was different from the 3 others! After I made sure that it is the same, I finally got the result that I was looking for: