addConstraintSegmentsInSingleTriangle crash

[ldpzgz]

system: ubuntu 20.4 on vmware compile: g++ 8 cpu: intel

I use this library to solve self-intersect triangles, it's always robust and fast, but I found it may crash when proccess some meshes. I try to debug it and found that it assert failed in this function: addConstraintSegmentsInSingleTriangle

I have several such mesh files, but I can't attach it on github, where should I send such a file to you?

[sloriot]

https://gist.github.com/ might be an option.

[ldpzgz]

I can't visit this page now, I must use vpn, I'll attach that file on this page several hours later

[mlivesu]

I you wish to share a failure case for us to take a look at, you should just drag and drop a zip file containing the mesh in the bar below the text box where you prompt your messages

[ldpzgz]

here is the file,just for debug please test.zip

[ldpzgz]

octree_cinolib branch

[mlivesu]

here is the file,just for debug please test.zip

I am not sure how should we reproduce your issue. Booleans take two arguments and a boolean operator. You shared with us a single mesh, were apparently intersections were already solved. How should we process it?

[ldpzgz]

1 load mesh 2 and then call this function: inline void solveIntersections(const std::vector &in_coords, const std::vector &in_tris, point_arena &arena, std::vector &out_coords, std::vector &out_tris)

I just use it to solve intersections on mesh

[ldpzgz]

std::vector<double> in_coords, out_coords;
std::vector<uint> in_tris,out_tris;
load(filename, in_coords, in_tris);
point_arena arena;
solveIntersections(in_coords, in_tris, arena, out_coords, out_tris);

[mlivesu]

I have taken a look at your case and indeed there seems to be a bug in our code (an assertion is failing). I am not sure why this is happening, it will require us some time to figure this out. Thanks for letting us know and for giving us a failure case we can use for debugging

[ldpzgz]

Thank you for your talent work, we have tested about 8000 wild meshes ,only four of them has this problem, next step, we'll use this mesh bool to solve intersections between connected components

[matschreyer]

Hello, could you please provide an update on the progress of this issue? I encountered a similar problem on arm64/m1 (asserts in addConstraintSegmentsInSingleTriangle while subtracting fairly simple geometries: two boxes and one sphere). I'm trying to determine if this is a bug or if the issue is related to the algorithm itself. Thank you for your help!

[gcherchi]

Hi, I have committed a fix on another portion of the code, which could also indirectly fix this problem. Can you pull the new version and test it again? If the problem persists, please send us the simple geometries you have mentioned. Thanks.

[matschreyer]

Thank you so much for the super quick response and fix! I tried it, but unfortunately, the assert still appears at assert(intersected_edges.size() > 0); in line 492 of triangulation.cpp. My system is Ubuntu (via Docker) on a Mac with arm64 architecture. I've tested it with several compilers, and the error seems to be independent of them. If you happen to have a similar system, I would greatly appreciate it if you could take a look into it.

When using the command: mesh_booleans subtraction sphere.stl small_box.stl big_box.stl out.stl it fails with a segfault in release and with an assert in debug.

Here are the three meshes: meshes.zip

In contrast to the behavior above, the command with only the first two meshes mesh_booleans subtraction sphere.stl small_box.stl out.stl works.

Thank you again for your help!

[gcherchi]

Looking at the meshes you sent me, I see that they are not "well-formed." All the faces and vertices are duplicated, thus forming self-intersections. One of the requirements of our algorithm (as you can read in our paper) is that the single meshes must be self-intersection free.

[matschreyer]

Thank you a lot for taking a look at it! Where did you noticed the self-intersections and duplicates? The mesh_booleans_inputcheck suggests that they are in good condition:

mesh_booleans_inputcheck sphere.stl
Manifold check: passed
Watertight check: passed
Local  Orientation check: passed
Global Orientation check: passed
Intersection check: passed

mesh_booleans_inputcheck small_box.stl 
Manifold check: passed
Watertight check: passed
Local  Orientation check: passed
Global Orientation check: passed
Intersection check: passed

mesh_booleans_inputcheck big_box.stl   
Manifold check: passed
Watertight check: passed
Local  Orientation check: passed
Global Orientation check: passed
Intersection check: passed

Vtk also shows 8 vertices for both boxes. I'm unsure what I might have missed.

[gcherchi]

Yes, you're right, there are no duplicated faces, but there is something strange. For example, opening small_box.stl I have 36 vertices (while I would expect to have 8 vertices on a cube).

[matschreyer]

Okay, that looks really wrong! I'll try to fix it, and I'll give you an update if the issue keeps happening. Thanks again for your help!

[matschreyer]

@gcherchi Sorry for bothering you on this subject again. From what I observed in your screenshot, it appears that you are using Meshlab. It seems that Meshlab automatically triples the number of vertices by default/bug for stls. I've tested by clearing with 'Remove Duplicate Vertices,' exporting the file, and reimporting it, but the number of vertices jumps back to 36.

I even tried different inputs, such as the Stanford armadillo, importing it as .ply, exporting it as .stl, and reimporting it as .stl, and every time, Meshlab triples the number of vertices! So, I think that my simple meshes should be okay.

[gcherchi]

And if you unify the vertices and export the file in .ply/.obj format, do you still obtain the same crash?

[matschreyer]

Yes, the segfault/assert issue still persists. These are the repaired meshes in OBJ format without any duplicate vertices. meshes_as_obj.zip

The failing command is: mesh_booleans subtraction sphere.obj small_box.obj big_box.obj out.obj

[gcherchi]

I tested your models. The algorithm works well on my side (no crashes reported). Furthermore, it produces the correct result, i.e., an empty mesh. The command you call performs sphere \ (small_box U big_box) (see section 6.4 of the paper). The result of the union is a box that entirely contains the sphere, so the result of the subtraction is empty. What result exactly did you expect to achieve with this command?

[matschreyer]

Thanks for testing it! I must admit the example may not be the best, but I also expected an empty mesh in this case. Just to confirm, did you use an ARM64-based Mac for testing? I found that this example works for me on AMD64 systems, but not on the "new" M1 ARM64 architecture.

[gcherchi]

I'm testing it on the macbook pro with M1.

[ldpzgz]

Good news! but, this issue seems still there

I pulled the code, and test the file "test.obj" (in test.zip above comment) with following code: int main(){ std::vector in_coords, out_coords; std::vector in_tris,out_tris;

load("test.obj", in_coords, in_tris);
point_arena arena;
solveIntersections(in_coords, in_tris, arena, out_coords, out_tris);
return 0;

} I tested it on windows 11, visiual studio 2022

[gcherchi]

Dear @ldpzgz, I'm not able to understand your comment on this thread. Which model have you tested? This is the repository of the Booleans operations, but your problem seems to be related to the Arrangement code (https://github.com/gcherchi/FastAndRobustMeshArrangements). The arrangement portion of the code in the current repository is a custom arrangement for the Booleans purposes, but it seems you need the general case, so you should use the code I linked to you.

[ldpzgz]

@gcherchi I have opened a new issue in this project: (https://github.com/gcherchi/FastAndRobustMeshArrangements)