Failure to substraction

[QuimMoya]

Hello
It seems that at some point boolean substraction fails. I think the input geometry is right. Not sure, but maybe elalish is failing, so i decided to open an issue.

These are the objects:
build.zip
In the zip you have the first geometry, the geometries to substract and the result.

Thanks for your time.

[pca006132]

Maybe you can first check the input geometry with the IsManifold method?

[elalish]

Agreed; this actually looks like valid output for marginal input (meshes that have faces that are coplanar or nearly so). Due to floating-point rounding error, your positions are not really certain. Therefore it's helpful to think of what you would expect the result to look like if your objects were moved a little (Precision()) in different directions. In general we consider any of those potential solutions to be valid output. For cases of exact floating-point equality we do a little better, but that's hard to attain especially with externally-created geometry.

[QuimMoya]

I see

Maybe the solution could be to scale the negative solid by a small factor, like x1.001.

Thank you.

[QuimMoya]

Hey @elalish , Just for curiosity, are you going to implement fuzzy booleans in elalish/manifold to solve these rounding errors?

[elalish]

No, I won't. This library intentionally avoids any form of tolerance in the Booleans in order to make them topologically reliable. As a user of the library, you'll either need to avoid creating those marginal cases in the first place, or be very careful with your rounding error to ensure the marginal cases are floating-point equal (which Manifold's transformations help with to some degree).

[QuimMoya]

We don't have control over the geometries that come to us. To prevent these rounding errors we will be forced to try correct them but this is really difficult. Is there any other option for us using manifold?

[elalish]

Can you give me more details about your workflow? Why do you get a lot of nearly-but-not-quite-aligned surfaces?

[QuimMoya]

Of course

We receive geometry from IFC files. This is like a PDF of 3D architectural models. It means that these models are not intended to be modified but only represented.
IFC defines geometry by applying some boolean functions, so we need to apply these functions on the geometry we receive. The problem is that sometimes we receive geometry that has some issues like the one we are discussing here.

[elalish]

I see, thanks. I would recommend you apply a tolerance using a similar system to how we handle symbolic perturbation internally (for exactly aligned surfaces). For any boolean op: A op B, for union, expand A and for difference and intersection, contract A. To apply a tolerance, move every vertex in the direction of its pseudo-normal (for expansion, opposite for contraction) by some distance. This handles most cases quite well. There are some complex ones that will break it, but if you want to handle everything you'll need to inspect the faces individually.

Also, if you're applying transforms to these inputs, you may want to round those too to avoid accruing errors. Since 90-degree rotations are common, yet cos takes radians, often the matrix ends up with eps elements instead of zeros and ones.