artem-ogre / CDT

Constrained Delaunay Triangulation (C++)

Home Page:https://artem-ogre.github.io/CDT/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Failure in eraseOuterTriangles

LeoPizzo1 opened this issue · comments

Ciao,
I am experiencing a quite strange failure in eraseOuterTriangles.
First of all I create a regular grid:
image
I add 4 points to the tessellation:
image
I ask to connect them via a set of 4 edges:
image
Finally I ask to erase the outer triangles and the result is an empty triangulation.
Do you have any idea of why it is happening?

The code to reproduce it is below.

void test( )
{
  CDT::Triangulation<double> triangulation;

  CDT::initializeWithRegularGrid( 0., 3., 0., 4., 3, 4, triangulation );
  std::vector<CDT::V2d<double>> vCoords;
  vCoords.reserve( 4 );
  vCoords.emplace_back( CDT::V2d<double>::make( 0.5000000000000000, 0.5000000000000000 ) );
  vCoords.emplace_back( CDT::V2d<double>::make( 0.5000000000000000, 3.5000000000000000 ) );
  vCoords.emplace_back( CDT::V2d<double>::make( 2.5000000000000000, 3.5000000000000000 ) );
  vCoords.emplace_back( CDT::V2d<double>::make( 2.5000000000000000, 0.5000000000000000 ) );
  std::vector<CDT::Edge> vBoundEdges;
  vBoundEdges.reserve( 4 );
  vBoundEdges.emplace_back( CDT::Edge( 0, 1 ) );
  vBoundEdges.emplace_back( CDT::Edge( 1, 2 ) );
  vBoundEdges.emplace_back( CDT::Edge( 2, 3 ) );
  vBoundEdges.emplace_back( CDT::Edge( 0, 3 ) );
  triangulation.insertVertices( vCoords );
  triangulation.insertEdges( vBoundEdges );
  triangulation.eraseOuterTriangles( );
  if( triangulation.triangles.empty( ) )
    throw std::runtime_error( "No triangles after erase?" );
}

Thank you for the issue!
I can reproduce it, will take a closer look.

This bug does not impact normal triangulation: only custom grids. The reason is that we re-use the sentinel value indicating outermost edges (no adjacent triangle on one side) for representing dangling edges during pseudo-polygon triangulation. It is not possible that super-triangle edge is included in the pseudo-polygon, so this only affects custom grid super-geometry.

Here's a temporary fix for the issue: 174-bugfix-supertri
If you are blocked you can use this branch for now. Another work-around is to ensure that no points are inserted in the outermost cells of the grid.

Going forward I will re-implement initializeWithRegularGrid and co. to insert the grid inside super-triangle. This will remove the need to handle special cases caused by custom super-geometries:

Instead of this:
Screenshot from 2024-05-06 13-58-43
It will be this:
Screenshot from 2024-05-06 14-01-05

Thanks a lot for your analysis.
Frankly, I guess it is better to avoid the creation of the supertriangle in this case.
The grid, generally, could be quite big, and as result you will need to add hundred of triangles, knowing that you just need to delete them afterwards.
For the general speed, avoiding unnecessary dynamic allocations is a must (for my experience).
Not sure what will be the impact of the additional if branch on the speed, but I guess it will have a lower impact.