Clean mesh .NET

Hi,

Is there any possibility to clean such mesh using RhinoCommon.
The mesh sometimes has self intersecting faces and edges on top of each other.

For example:
CleanUp.3dm (75.7 KB)

Where are these meshes coming from?

This is a result of 3 mesh boxes passed to C++ CGAL mesh boolean union and returned via PInvoke in NET Grasshopper. I did this on purpose to check result of coincident mesh faces.

I tried vertex alignment and other typical welding/repair operations.

It seems I cannot avoid rounding problem even with this native library.

Is there a possibility to use double point vertices for meshes instead of floats in Rhino?

Yes, just add the data as doubles instead of singles. See the several Add overloads for that:

https://developer.rhino3d.com/api/RhinoCommon/html/T_Rhino_Geometry_Collections_MeshVertexList.htm

FWIW, double precision is not going to help you with bad geometry though.

There are a couple of faces that aren’t entirely degenerate, but aren’t really very nice either.

I tried a quick cleanup in Blender to see how well it fares, but in the end here I also needed to do some manual cleanup afterwards

Thanks Nathan, it seems this boolean operation with coincident faces produce really bad meshes.

Happy New Year;)

Hi @Petras_Vestartas

do you till have the input geometry?
I’m interested to see where problems will arise when this will be handed over to the new boolean operator, probably in V8 WIP.

Thanks,

Giulio


Giulio Piacentino
for Robert McNeel & Associates
giulio@mcneel.com

:star_struck: that’s a nice start for the new year!

1 Like

Hi @piac,

I am uploading both mesh inputs and compiled library from CGAL, so that you can try.
It seems CGAL is more robust and fast than Rhino boolean methods.
Coincident mesh face intersection have issues regarding mesh quality, I think due to passing imprecise point values from Rhino mesh to C++ side. This is also what CGAL documentation says. For multiple operations I am trying to implement code that does boolean intersection in C++ rather than constantly passing meshes between .NET and C++. In my work it could be enough.

These are some tests already done:

And here is the files as requested. I was honestly surprised that boxes in the bottom even works. The boolean is performed with red and brown boxes to obtain boolean difference/intersection/union.
x64.zip (658.5 KB)

In the attached example you will see skinny mesh faces for two boxes when these boxes are rotated randomly in space and when there is no rotation result is good. I tried to ask question here to know if there is any way to detect such thin mesh faces and somehow repair such faces.
MeshBooleanCGAL.gh (8.7 KB)

The code is compiled from this manual:
https://doc.cgal.org/latest/Polygon_mesh_processing/index.html

There are also bunch of other libraries such as libigl (some sort of CGAL version), Cork and latest siggraph2020 implementations that are worth to try as well and test with the new Rhino Boolean.

1 Like

It seems both CGAL and LIBIGL methods are quite good considering robustness. CGAL is really fast and LIBIGL allows to track CSGtrees. Bellow is LIBIGL implementation. Coincident faces boolean causes issues mainly due to floating point error by transferring data between Rhino meshes and C++. But if you can avoid such scenarios it really good libraries for meshes. I could share the implementation in Rhino. Maybe someone could tell me if GPL licenses are fine for open-sourcing code to Rhino plugins?

Did you try PMP?

// Rolf

Not yet, but I ll do;)

I was searching for mesh boolean methods that could be more robust. PMP does not have yet have mesh boolean methods but a good part, it is up to date and well maintained. The methods from C++ to C# for now working fine, I will test them with in my work to see all the tricky parts considering both LibIgl and CGAL.

1 Like