libigl / tetgen

This is a mirror of the latest stable version of Tetgen.
Other
94 stars 42 forks source link

Failing generation for large or small meshes, it shows some type of memory leak or corruption #4

Closed syedalamabbas closed 6 years ago

syedalamabbas commented 6 years ago

I know that this is purely a tetgen issue rather than libigl issue, but due to the embedding and a lack of official tetgen presence on github I am documenting this here.

I have a mesh with V of dimensions 2663718 x 3 and F with 887906 x 3 that I can load and view in libigl.

However when I try to tetrahedralize it (I tried with different switches and combinations, including verbose to better understand) it fails at this code in tetgen.cxx crying read access violations, smaller meshes seem to pass through, although not all of them are able to make through this process. It does totally feel like not a memory issue since even something as small as
igl::readOFF(TUTORIAL_SHARED_PATH "/camelhead.off", V, F); fails with same stupid error.

`/////////////////////////////////////////////////////////////////////////////// // // // ~memorypool() Free to the operating system all memory taken by a pool. // // // ///////////////////////////////////////////////////////////////////////////////

tetgenmesh::memorypool::~memorypool() { while (firstblock != (void ) NULL) { nowblock = (void ) *(firstblock); free(firstblock); firstblock = nowblock; } } `

alecjacobson commented 6 years ago

It might just be as simple as your machine not having enough memory. As far as I know, tetgen is "in core". So if it can't allocate memory it will just die.

syedalamabbas commented 6 years ago

Maybe its a memory issue, but I suspect there is some operation that has unhandled exception coming from tetgen, even simple datasets like this doesn't work giving the same error igl::readOFF(TUTORIAL_SHARED_PATH "/camelhead.off", V, F); while, igl::readOFF(TUTORIAL_SHARED_PATH "/bunny.off", V, F); - works

alecjacobson commented 6 years ago

Are you sure that the camel fails due to memory issues? I would suspect that tetgen will fail because the mesh has an open boundary.

syedalamabbas commented 6 years ago

Well maybe that is the cause, but the exception that I see at top level is the same. I use visual studio 2017 btw. So perhaps it might be the case with the large mesh too. Ok, I will attempt with closed boundary and then test it, is there a function that can do it already in libigl ?

alecjacobson commented 6 years ago

Not in libigl. I have a crude fill_holes routine in gptoolbox. Otherwise I'd recommend using something like meshlab or meshfix.

syedalamabbas commented 6 years ago

Ok, thanks will try and test.

syedalamabbas commented 6 years ago

Here I will try to provide more details about what I am trying and what is not working. Still it gives errors.

I am using a project from here : http://gl.ict.usc.edu/Research/DigitalEmily2/

  1. I downloaded the Emily data in wavefront format. Then I closed the mesh's boundary by blender grid fill like so: image

  2. I tried exporting .obj from blender and tried to read using igl/readOBJ.h and it fails to read.

  3. I tried with .ply and that fails too.

  4. I tried reading with .stl format and it works, here is the loaded mesh, image

image

  1. I then go for tetrahedralizing the mesh and it gives me error : image

"flipnm" assertion is failing - looks like it encounters some type of degenerate configuration.

image

syedalamabbas commented 6 years ago

I finally was able to resolve this issue today. See the solution here. Its not the tetgen issue obviously, the mesh had to be made amenable here. See the solution at stack overflow.