Failure of boolean subtraction

[chpark1111]

Ultimately, I want to boolean subtraction (part - mesh) and calculate the volume with given below 2 meshes. But it gives me a segmentation fault when I calculate the volume or turn the subtracted manifold into a mesh.

Can you guys check whats the error?

I'll providethe part and mesh as txt file under part.txt mesh.txt

[chpark1111]

Also with the above mesh, when I turn the mesh into manifold and turn it back to mesh, I get a open mesh! I think that has something to do with the failure above.

It means that manifold to mesh creates an open mesh which is a serious problem.

[elalish]

So first, can you be very specific about what your workflow is and what apps/libraries are being used to test the results? Keep in mind that most 3D file importers and exporters change the mesh, often in an attempt to make something manifold that isn't, but just as often doing the opposite.

The seg fault sounds like a definite bug. Any chance you can turn it into a simple-ish test akin to these? https://github.com/elalish/manifold/blob/master/test/mesh_test.cpp#L639

[chpark1111]

I checked that it makes a non-watertight mesh with the below codes! I just do nothing but loading it to pymanifold mesh and manifold and just turn them back to mesh. But it gives us a non-watertight mesh. I use trimesh library to check the watertighness and meshlab to visualize the mesh.

Above prints out True, False.

And about the seg-fault, I'll try to make the tests in c++ but it will be definitely hard to reproduce the results without loading the above meshes. Do you mean "simple-ish " as reproducing the seg-fault without using those meshes? But before this, isn't the above a problem? If just simple reconstruction is ill, I think manifold subtraction will definitely not work well.

[elalish]

Thanks, so you're using Trimesh to import our mesh and to check watertightness. That's not trivial, as we don't know what the Trimesh importer does with the mesh (does it try to merge duplicate verts?) and we don't know how it checks watertightness (ours is one of many definitions of manifoldness). See a similar discussion in https://github.com/elalish/manifold/issues/304#issuecomment-1368506302

Anyway, it would be great to understand the details of other libraries like Trimesh so we can document what is expected, how to properly interface with them, and even file bugs/feature requests. It'll help a lot if we can manage to reduce the test mesh down to a small number of triangles so we can find differences in the round-trip by reading the vectors in std out.

[chpark1111]

Oh sorry about the missing details.. I didn't know that it's not a trivial thing and the extra-processing of the libraries. I'll try to explore little deeper about the current problem and tell you what I've found. The water-tightness is just one thing I'm suspecting but like you said seg-fault is a problem. I'll first track where the segfault is happenning!

[pca006132]

Just build with debug information enabled and give the gdb backtrace should give us a rough idea about what is causing the problem.

cmake -DCMAKE_BUILD_TYPE=Release -DMANIFOLD_PAR="NONE" -DMANIFOLD_DEBUG=1 -DCMAKE_CXX_FLAGS="-fsanitize=address,undefined -g"-DMANIFOLD_PYBIND=on ..

[danielyan86129]

Curious @elalish there must be routines in pymanifold that check if a mesh is manifold and watertight right?

@pca006132 can you comment out fix_normals() (as it might be doing something), and try to use those routines and print the status after you call .from_mesh() and .to_mesh()? Also, when you call trimesh.Trimesh() set this to False:

process : bool
          if True, Nan and Inf values will be removed
          immediately and vertices will be merged

[pca006132]

Yeah we have IsManifold to check for manifoldness according to the definition in the project wiki:

Every edge of every triangle must contain the same two vertices (by index) as exactly one other triangle edge, and the start and end vertices must switch places between these two edges. The triangle vertices must appear in counter-clockwise order when viewed from the outside of the manifold.

Although it seems that I forgot to export that to the python interface. Adding the function should be trivial though. There are also some additional checks that are only enabled when MANIFOLD_DEBUG is enabled, but enabling those checks may cause #297 and also slow things down a bit.

[chpark1111]

Oh sorry about the late response. I made the tetrahedral meshes with Tetwild libary which seems to generate degenerated tetrahedral meshes. I tried it with using process=False in tetmesh and given just used the manifold's meshIO. I think this is just the problem of the mesh not the library. I'll close the issue.. Sorry for bothering you guys.

[elalish]

@chpark1111 Not a bother! Thanks, and we learned something useful from @danielyan86129 about process: false in pymanifold, which we should probably document somewhere.