holed mesh output when converting a level set to mesh

[Khanh Ha]

My output mesh from VolumeToMesh shows some triangle holes when I pass it a difference level set, made from two standard sphere level sets.

Here's the code:

grid0 =

openvdb::tools::createLevelSetSphere<openvdb::FloatGrid>(

/*radius=*/50.0, /*center=*/openvdb::Vec3f(1.5, 2, 3),

/*voxel size=*/.5f, /*width=*/3.0);

grid1 =

openvdb::tools::createLevelSetSphere<openvdb::FloatGrid>(

/*radius=*/50.0, /*center=*/openvdb::Vec3f(20.5, 20, 20),

/*voxel size=*/.5f, /*width=*/3.0);

openvdb::tools::csgDifference(*grid1, *grid0);

 

Here's the holed mesh: 

Did I do anything wrong when making the difference level set from two sphere level set? Or I missed some configuration information when converting to the mesh? Or is it the error from the volumeToMesh implementation?

[Khanh Ha]

VolumeToMesh code section:

openvdb::tools::VolumeToMesh mesher(

grid->getGridClass() == openvdb::GRID_LEVEL_SET ? 0.0 : 0.01);

mesher(*grid);

[Mihai Aldén]

I've verified the polygonal surface that the VolumeToMesh tool produces for this case and it's perfectly fine, see attached obj file for reference.

Please note that this tool only produces quads, when no adaptivity is selected, so it is a bit odd that you are getting triangle holes.

How are you visualizing this? Our standalone OpenGL viewer samples the level set gradient to produce surface normals and this approach is not always robust.

[Khanh Ha]

Hi Mihai Aldén,

I am using OpenVDB 3.101 built on VC10. It's so strange that your mesh doesn't show the small holes like in my case. I tried the OpenVDB viewer, but

the output mesh still shows holes. May be the holes in sphere-sphere intersection is quite small, so it doesn't happen in your computer. 

I tried VolumeToMesh with the difference level set between the armadillo model from the  openvdb website and  the sphere level set. The output mesh

show a lot of large holes as the below image

The source code:

openvdb::FloatGrid::Ptr grid0 = openvdb::tools::createLevelSetSphere<openvdb::FloatGrid>( 100.0, openvdb::Vec3f(1.5, 2, 3), .5f, 3.0);

openvdb::FloatGrid::Ptr grid1 = openvdb::gridPtrCast<openvdb::FloatGrid>(readGread("F:\\3D_data\\openvdb\\armadillo.vdb"));

openvdb::tools::csgDifference(*grid1, *grid0);

allGrids.push_back(grid1);

openvdb_viewer::Viewer viewer = openvdb_viewer::init("KhanhHH", /*bg=*/false);

viewer.open();

viewer.view(allGrids);

openvdb_viewer::exit(); 

This bug only happen when I pass the difference level set to VolumeToMesh. The mesh is still good when I pass the standard level set from the OpenVDB website.

 

 

 

 

 

[Khanh Ha]

A more clear picture

[Mihai Aldén]

Hi Khanh Ha,

I've tried applying various CSG operations and I don't get any surfacing errors, the tools::volumeToMesh output is always a closed manifold surface, no holes.

I was actually not able to exactly reproduce your last image from the setup you described and I also noticed that you are mixing different voxel sizes, the CSG tools require grids with matching transforms.

This is what I get using your setup for the sphere { radius 100, center (1.5, 2, 3), voxel size 0.5 half-width 3 }, no neutering. (The sphere grid is re-sampled to match the Armadillo model's transform, voxel size 0.1 .)

But let's move the sphere away from the Armadillo man's crotch to { radius 50, center (0, 100, -30), voxel size 0.1 half-width 3 }, this generates the following result:

The mesh output seems fine, I strongly suspect that you are experiencing a visualization error and not a mesh extraction bug. I can't really debug this much further we don't have access to Windows and VisualStudio.

What version of OpenVDB are you using? The latest version is 3.1

Best,

Mihai

[Khanh Ha]

Hi Mihai Aldén,
Does holes occur when you do not resample sphere to match Amardialo? I will
try it to see the result. I am using a OpenVDB for a sculpting program,
which requires to combine
many subparts to make the model like stiching arms, limbs, body to make
human. But I am afraid that resampling subparts (which seesm to cost so
much time: convert level set
to mesh, transform points, and then, reconvert mesh to level set) will cost
so much time, so can't meet the real-time requirement.