Closed syedalamabbas closed 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.
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
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.
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 ?
Not in libigl. I have a crude fill_holes
routine in gptoolbox. Otherwise I'd recommend using something like meshlab or meshfix.
Ok, thanks will try and test.
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/
I downloaded the Emily data in wavefront format. Then I closed the mesh's boundary by blender grid fill like so:
I tried exporting .obj from blender and tried to read using igl/readOBJ.h and it fails to read.
I tried with .ply and that fails too.
I tried reading with .stl format and it works, here is the loaded mesh,
"flipnm" assertion is failing - looks like it encounters some type of degenerate configuration.
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.
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; } } `