Dealing with extra triangles after boolean comparison (that shouldn't be there)

[elias-bananaz]

I'm doing a boolean subtraction in order to find what changed between one mesh and another.

In about half of my cases I have a lot of extra slivers that protrude from the result, some connected to meshes that are correct, and some disconnected.

Here's one example:
This is doing one mesh minus the other, and the only thing that changed is that the holes have moved by some offset, so only the big solid shapes should appear.

These long triangles at the bottom shouldn't appear:

and these are connected to the part but should not have been added:

Things I tried:

• I'm calling Decompose on the result to treat each lump separately (what you see as different colors in the screenshots), and I'm filtering out some lumps by volume (only add if volume > 1e-3). This filters some but not all cases, and I don't think it's viable to just keep increasing this number
• Tried SetTolerance(1e-3) and RefineToLength(1) on the mesh before doing the boolean operation

Interestingly, if I find the common area (Intersect) instead of Subtract, I get only one lump without any extra triangles, which seem to me that it means it's able to find correctly the parts that are common and should be removed when doing subtraction.

What else can I do improve the results?

[pca006132]

1. What is the version you are using? We have quite a lot of changes related to decimation recently, so we need to know the specific revision you are using.
2. Can you give a simple reproducible example that we can play with? Ideally with manifoldcad.org. It seems that you did postprocessing with the mesh (things look like quads?), so it is hard to guess what is wrong with the original output.

[pca006132]

I see

[elias-bananaz]

I was also able to reproduce with this snippet:

manifold::MeshGL mesh1 = manifold::ImportMesh("C:\\Tmp\\Rev1.glb");
manifold::MeshGL mesh2 = manifold::ImportMesh("C:\\Tmp\\Rev2.glb");
if (!mesh1.Merge())
{
	std::cerr << "Warning: mesh1 is not manifold after merging.\n";
}
if (!mesh2.Merge())
{
	std::cerr << "Warning: mesh2 is not manifold after merging.\n";
}

manifold::Manifold mBody1(mesh1);
manifold::Manifold mBody2(mesh2);
auto resA = mBody1 - mBody2;
auto resB = mBody2 - mBody1;
if (resA.Status() != manifold::Manifold::Error::NoError) {
	std::cerr << "resA is invalid manifold! " << resA.Status() << std::endl;
}
if (resB.Status() != manifold::Manifold::Error::NoError) {
	std::cerr << "resB is invalid manifold! " << resB.Status() << std::endl;
}

manifold::ExportMesh("C:\\Tmp\\ResA.glb", resA.GetMeshGL(), manifold::ExportOptions());
manifold::ExportMesh("C:\\Tmp\\ResB.glb", resB.GetMeshGL(), manifold::ExportOptions());

[pca006132]

Can you please attach the glb files? Otherwise we can't look at it either.

[elias-bananaz]

Sure, the files are in this zip: https://github.com/user-attachments/files/18963447/Revs.zip

[pca006132]

Thanks, will have a look when I have time.

[elalish]

In addition to what @pca006132 said, be aware that this is pretty much expected behavior. Subtracting exactly aligned surfaces is indeterminant because an epsilon perturbation one way gives you no surface and the other way gives you an epsilon-thick surface. If you manage to introduce zero floating point error into your verts (which is hard), we do our best to choose symbolic perturbation directions that tend to remove thin surfaces and such, but we can't do it correctly in all situations. Decimating them away after the fact is also an imperfect solution, as you've found.

We test our Boolean correctness primarily on volume, as floating-point error easily leads to thin shards, that while ugly, are not entirely wrong.

[elias-bananaz]

Thanks for the explanation @elalish , I'm still trying to fully understand it 🙂
I'll give you a bit more background. I'm loading Step files, which are saved as B-Rep, and meshing them (using OCCT)
So if I could know beforehand if 2 surfaces are exactly the same, and I could make sure that the meshing for those surfaces are exactly the same, would that help removing the overlapping faces?
Also, how come that finding the intersection like I described above gives an accurate result, with no shards? Isn't the logic to determine if 2 surfaces are overlapping the same?

[elalish]

Making the vertices floating-point equal would help, but wouldn't guarantee a total absence of shards. You will find the same problem with intersections, but they'll come up in different situations. For intersections and unions, the problem will be with objects that almost overlap - the shards will be more obvious in the intersection case (since you expect an empty result), but the unions will have the same problem hidden inside. With exact verts and relatively simple shapes, they should all work as desired.

[elias-bananaz]

@elalish @pca006132
Would treating the loaded models as SDF help in this case?
I'm thinking of creating a grid where each point samples the distance to the original b-rep surface, and use that with LevelSet.
I was reading this discussion and I'm not sure if I understood correctly if this is ready for usage or not, and if using an SDF approach could help reduce artifacts in my case.

[pca006132]

I don't think SDF can help in your case. The SDF conversion is lossy. It can probably reduce artifacts but at the expense of accuracy.

[elias-bananaz]

Ok, tried SDF, it reduced accuracy and increased artifacts 😄 (the light blue and yellow stripes shouldn't be there - as well as all the smaller triangles)