stitch_borders_example output error

[citystrawman]

Please use the following template to help us solving your issue.

Issue Details

I am studying the polygon mesh processing stitch_borders_example, and I think this example shows that by using stitch_borders(), it will stitch the duplicated nodes, I ran this program and from the off file we can see that it actually does merge duplicated nodes:

quads_to_stich.off:
OFF
20 8 0
1 0 0
0.75 0 0
0.5 0 0
0.25 0 0
0 0 0
0 1 0
0.25 1 0
0.5 1 0
0.75 1 0
1 1 0
1 1 0
0.75 1 0
0.5 1 0
0.25 1 0
0 1 0
0 2 0
0.25 2 0
0.5 2 0
0.75 2 0
1 2 0
4  5 6 3 4
4  3 6 7 2
4  1 2 7 8
4  1 8 9 0
4  15 16 13 14
4  13 16 17 12
4  11 12 17 18
4  11 18 19 10

mesh_stitched.off:
OFF
15 8 0

1 0 0
0.75 0 0
0.5 0 0
0.25 0 0
0 0 0
0 1 0
0.25 1 0
0.5 1 0
0.75 1 0
1 1 0
0 2 0
0.25 2 0
0.5 2 0
0.75 2 0
1 2 0
4  5 6 3 4
4  3 6 7 2
4  1 2 7 8
4  1 8 9 0
4  10 11 6 5
4  6 11 12 7
4  8 7 12 13
4  8 13 14 9

however, in the terminal output, it is shown as follows:

Before stitching :
         Number of vertices  :  15
         Number of halfedges :  44
         Number of facets    :  8
Stitching done :
         Number of vertices  :  15
         Number of halfedges :  44
         Number of facets    :  8

I dont know if this is a bug ?

Source Code

Environment

• Operating system (Windows/Mac/Linux, 32/64 bits):
• Compiler:
• Release or debug mode:
• Specific flags used (if any):
• CGAL version:
• Boost version:
• Other libraries versions if used (Eigen, TBB, etc.):

[MaelRL]

You are probably using a CGAL::Surface_mesh and getting the number of elements through num_vertices() and similar functions.

As the doc indicates:

num_vertices() may return a number larger than std::distance(vertices(g).first, vertices(g).second). This is the case for implementations only marking vertices deleted in the vertex container.

This is because the surface mesh will have "garbage" (i.e., removed elements) after calling PMP::stitch_borders: duplicate elements have been removed during stitching. In CGAL::Surface_mesh, these are not purged from memory unless you call collect_garbage() and thus the number of elements through num_vertices(sm) is unchanged.

If you want the exact number of elements without collecting garbage, you can use the number_of_vertices member function of the CGAL::surface_mesh, or std::distance(...), or vertices(sm).size(), or CGAL::internal::exact_num_vertices(sm), ...

[citystrawman]

You are probably using a CGAL::Surface_mesh and getting the number of elements through num_vertices() and similar functions.

As the doc indicates:

num_vertices() may return a number larger than std::distance(vertices(g).first, vertices(g).second). This is the case for implementations only marking vertices deleted in the vertex container.

This is because the surface mesh will have "garbage" (i.e., removed elements) after calling PMP::stitch_borders duplicate elements have been removed during stitching. In CGAL::Surface_mesh, these are not purged from memory unless you call collect_garbage() and thus the number of elements through num_vertices(sm) is unchanged.

If you want the exact number of elements without collecting garbage, you can use the number_of_vertices member function of the CGAL::surface_mesh, or std::distance(...), or vertices(sm).size(), or CGAL::internal::exact_num_vertices(sm), ...

but the output shows the numbe of vertex after stitching, not before stitching, which is weired. (I just use the code pulled from git, the branch is 5.5.x)

[afabri]

@citystrawman can you please put a self contained example on gist.github.com so that we can reproduce/fix.

You refer to an example, but the example for stitching uses Polyhedron and not Surface_mesh.

[MaelRL]

You are probably using a CGAL::Surface_mesh and getting the number of elements through num_vertices() and similar functions. As the doc indicates:

num_vertices() may return a number larger than std::distance(vertices(g).first, vertices(g).second). This is the case for implementations only marking vertices deleted in the vertex container.

This is because the surface mesh will have "garbage" (i.e., removed elements) after calling PMP::stitch_borders duplicate elements have been removed during stitching. In CGAL::Surface_mesh, these are not purged from memory unless you call collect_garbage() and thus the number of elements through num_vertices(sm) is unchanged. If you want the exact number of elements without collecting garbage, you can use the number_of_vertices member function of the CGAL::surface_mesh, or std::distance(...), or vertices(sm).size(), or CGAL::internal::exact_num_vertices(sm), ...

but the output shows the numbe of vertex after stitching, not before stitching, which is weired. (I just use the code pulled from git, the branch is 5.5.x)

You are right, sorry, that's not what happened.

What happens is that the example is using the function CGAL::Polygon_mesh_processing::IO::read_polygon_mesh() from the Polygon_mesh_processing package. As the doc indicates, the function applies a few repairing techniques after reading the raw input by calling CGAL::Polygon_mesh_processing::repair_polygon_soup(). Indeed, if you define the macro CGAL_PMP_REPAIR_POLYGON_SOUP_VERBOSE, you will see:

$ ./stitch_borders_example input.off 
Repairing soup with 20 points and 8 polygons
Removed (merged) 5 duplicate points
...

If you use *CGAL*::IO::read_polygon_mesh(...), that is the IO function which does not perform any repair, then you will get what you expected:

Before stitching : 
	 Number of vertices  :	20
	 Number of halfedges :	52
	 Number of facets    :	8
Stitching done : 
	 Number of vertices  :	15
	 Number of halfedges :	44
	 Number of facets    :	8

[citystrawman]

@citystrawman can you please put a self contained example on gist.github.com so that we can reproduce/fix.

You refer to an example, but the example for stitching uses Polyhedron and not Surface_mesh.

Hi, this issue is explained by MaelRL. Thank you!