Assertion raised by "Mesh_3/mesh_polyhedral_domain_with_features.cpp" demo when using a different OFF file

[sampotter]

First, apologies if the following is user error. I'm still getting acquainted with CGAL, having only just started using it.

I'm trying to write some code that uses the basic functionality provided in the "Mesh_3/mesh_polyhedral_domain_with_features.cpp" demo. Indeed, if I build the demo with debug information and run it with my own OFF file (attached below), CGAL raises the following assertion:

CGAL error: assertion violation!
Expression : minimal_size_ > 0 || sq_d > 0
File       : /usr/local/include/CGAL/Mesh_3/Protect_edges_sizing_field.h
Line       : 753
Explanation: 
Refer to the bug-reporting instructions at https://www.cgal.org/bug_report.html
libc++abi.dylib: terminating with uncaught exception of type CGAL::Assertion_exception: CGAL ERROR: assertion violation!
Expr: minimal_size_ > 0 || sq_d > 0
File: /usr/local/include/CGAL/Mesh_3/Protect_edges_sizing_field.h
Line: 753
wabort trap: 6

Here's the OFF file that I'm using:

room.off.zip

If I run the demo with the "fandisk.off" file, I have no trouble.

It seems possible that this is a problem with my mesh, but I'm not sure how to interpret the assertion. I made sure to run this mesh through MeshLab and clean it up (deduplicate vertices, faces, etc.).

To build the demo, I used the following CMakeLists.txt file:

project (test)
cmake_minimum_required (VERSION 3.16)
set (CMAKE_CXX_STANDARD 17)
find_package (Boost REQUIRED COMPONENTS system thread filesystem)
find_package (CGAL REQUIRED)
add_executable (test test.cpp)
set_property (TARGET test PROPERTY CXX_STANDARD 17)
target_link_libraries(test PRIVATE CGAL::CGAL)

where "test.cpp" is just the "Mesh_3/mesh_polyhedral_domain_with_features.cpp" demo.

Environment

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

[lrineau]

Your input mesh has non-manifold edges.

That is probably easy to fix with CGAL tools.

@MaelRL, @sloriot, the geometry seems good, and geometrically manifold (as a set). But its has adjacent triangles that are not correctly correfined. Do we have a self-corefinement feature in CGAL?

[MaelRL]

You can use the undocumented function PMP::experimental::autorefine() which will make your boundary edges conforming (i.e. combinatorially compatible). You can afterwards call PMP::stitch_borders to merge conforming edges and get a single volume (see attached) on which Mesh_3 should run fine.

room_repaired.zip

[sampotter]

Oops! Thanks for the help... That was an easy fix. I ended up just fixing this problem manually (the mesh was originally made by hand in Blender), and was able to construct the tetrahedron mesh without any trouble.

I noticed that you marked this as "not a bug". I'm not familiar with CGAL's error handling philosophy, but it certainly seems like being notified by CGAL of this problem would be helpful (instead of CGAL raising an assertion somewhere deep in its internals).

@MaelRL Thank you for suggesting these functions, I'll give them a try.

Does CGAL have a function that can be used to detect when a mesh has nonmanifold edges? (Sorry if this is not the appropriate place to ask this question.)

[lrineau]

That is complicated. If we want to detect problematic inputs before the code of Mesh_3 starts:

• that would cost running time,
• and there are still complicated situations that we cannot detect with our current tools.

But I agree with. We should at least provide a method that users could call before running Mesh_3, to detect and inform about the situations we can detect.