union seams during mesh export

[doug-moen]

This model, seam.curv:

union [
    cube >> move[1,0,0],
    cube >> move[-1,0,0]
]

In the viewer:

When converted to an STL file using curv seam.curv -o seam.stl:

The problem is the seam down the middle, only visible in the exported mesh. The request is to modify mesh export so that the seam doesn't get get generated.

Originally reported by @lf94

[doug-moen]

There are workarounds. You can slightly overlap the two cubes, a workaround I am familiar with from OpenSCAD.
Lee reports that you can use smooth 0.001 .union instead of union. These workarounds are not good enough. You should get a clean STL export if you write the code in the simplest and most obvious manner.

Evidently the seam must exist in the SDF, even if it isn't visible using the viewer (the seam is even invisible using show_dist). I am also not able to detect a seam if I probe the SDF using the Curv interpreter. This is so weird, maybe there's a situation in the voxelizer where the SDF is being generated differently than in the interpreter or in the GPU. I don't know yet.

[doug-moen]

I have added a new mesh generator based on libfive Dual Contouring. The two mesh generators are:

• -Omgen=#smooth -- the original and still default mesh generator based on OpenVDB
• -Omgen=#sharp -- the new dual contouring mesh generator.

The #sharp mesh generator does not exhibit the problem of union seams. If the shape given in the original bug report is meshed using the #sharp generator, then the results look perfect, exactly as they look in the viewer, with sharp edges and no seam.

However, there are some models for which #sharp is not appropriate, and for which you still need to use #smooth. And I still haven't diagnosed the underlying problem that causes union seams in the #smooth generator.

[lf94]

@doug-moen this issue is apparent because of marching cubes right? Maybe if we forced an external offset on the models (while devving) it'd make this problem more apparent. I'm thinking depending on the export method picked (by default it'll be smooth), curv will apply or not apply this transformation. At least then users can adjust their models accordingly. In this example that'd equate to moving the boxes over N units that reflect the effects of what'd happen on smooth rendering.

[doug-moen]

I do not fully grok why union seams appear. I believe that it is related to how the distance field looks at short distances away from the surface. The surface itself does not have this seam.

The union seams are coming from the #smooth meshing algorithm exported by the openvdb library. The name of this meshing algorithm is not documented, but I believe it is an implementation of Dual Marching Cubes (which is different from Marching Cubes), or some variant of it.

Although I generally like the algorithm compared to many others that I have tried, there is this union seam problem. I think the problem would be solved by a variant of Dual Marching Cubes that places the triangle vertices directly on the surface of the shape.

Most SDF meshing algorithms available on the internet take as input a 3D grid of regularly sampled distance values. It's usually the case that none of these sampled distance values lies directly on the surface of the shape, so the surface has to be found by interpolation. My ideal solution is a variant of the algorithm that takes a function as an argument, instead of presampled values. The algorithm will initially sample the distance field in a grid pattern, then it will make hypotheses about the location of the shape's surface and call the distance function additional times to test these hypotheses. It will ask for more samples in regions where there is sharp curvature, and ask for fewer samples in areas where there is low curvature.

Libfive is sort of like this, in that you give it a function as an argument, except that it wants me to tell it what the gradient of the distance field is at a given point, and where the edges are, and I do not have this information, so I have to give it dummy or estimated information, and the results are not the best. I want an algorithm that figures out this information itself by sampling the distance field based on its own internal requirements.

I just found an algorithm that I haven't seen before by Roberto Grosso. It's a variant of Dual Marching Cubes that positions the triangle vertices on the surface of the shape. That's what I said I wanted above, right? https://link.springer.com/article/10.1007/s00371-021-02139-w

Grosso has iterated this algorithm a number of times. I tested his first iteration a number of years ago, but the quality of output was less than OpenVDB, so I didn't use it. This latest iteration is supposed to be an improvement, so it's worth checking out. What I liked about Grosso's code on github (back then) was that it was very small and simple (C++), and that there was a fast variant that runs on GPUs. Grosso's new algorithm still works from regularly sampled distance data, you can't pass it a function, so it still isn't the algorithm that I really want.

Usually when I have a great idea, somebody on the internet has already thought about it and implemented it. Not in this case, unless something new has appeared that I haven't seen yet, or I'm using the wrong search keywords.

[lf94]

https://github.com/rogrosso/tmc seems that latest paper's implementation is available here under the dmc/ folder!

And yeah; my comment is not about solving the problem but making it very obvious during development. If we can resolve it entirely that's awesome.

[doug-moen]

Never mind, I have already tested Grosso's latest version.

[lf94]

Do you know if this small space is determinable before rendering? Seriously it will be largely beneficial for me to apply an offset to make it visible during development than see it unexpectedly after rendering.