Mesh.CreateConvexHull3D returning Invalid Mesh

[TuomasLehtonen]

I ran some tests with the added Mesh.CreateConvexHull3D in RhinoCommon. Please see the attached GH file with internalized Point3d Lists for testing. List A gives a decent output whereas ListB returns an Invalid Mesh with lots of Mesh Faces. I have compared these against the QuickHull component.

Do I use it correctly or is there a bug?

List A

List B

ConvexHull3dRhinoCommon.gh (249.2 KB)

[martinsiegrist]

I get an open mesh which can be closed and has no self intersections.

ConvexHull3dRhinoCommon.gh (124.5 KB)

Might be a tolerance issue, no?

[dale (Dale Fugier)]

@MathiasFuchs_McN - can you have a look at this?

[laurent_delrieu]

In Nautilus I use this tool
Copyright 2019 Oskar Sigvardsson
*

OskarSigvardsson/unity-quickhull/blob/master/Scripts/ConvexHullCalculator.cs

There are no problems and it is fast.

Changing the tolerance doesn’t change things

[MathiasFuchs_McN (Mathias Fuchs)]

I get a valid mesh on both test sets, at the default 0.001 tolerance. I’ll have a look at why it’s not closed, but as @martinsiegrist noted, it is closable. What is your model tolerance?
Logged it under https://mcneel.myjetbrains.com/youtrack/issue/RH-81058

[martinsiegrist]

My tolerance is usually 0.001 and I’m using Rhino 8

[MathiasFuchs_McN (Mathias Fuchs)]

Thank you, yes, I meant the opener @TuomasLehtonen.

[TuomasLehtonen]

My Rhino model is in Meters with a tolerance of 0.01. I also tested 0.001 and 0.0001 and so on. It seems that now when I test the same file I shared here, I don’t get Invalid Meshes anymore, but the ConvexHull C# script component is still really slow. I am running the latest 8.6 SRC. I was probably running 8.5 SR previously.

BUT, the plot thickens. I think I found where the problem originates from. So in essence, the same C# script component can take only 18ms or 1300ms with the same list of points. Please try to reproduce the problem with these steps:

• Create a box in Rhino
• Reference that box in Grasshopper and use Populate Geometry with 1000 or 2000 points on that referenced Box
• Connect the populated points into the shared C# component → this will take a long time to calculate
• Internalize the same point list and copy-paste it onto another GH Canvas
• On that canvas, copy the same point container and paste it back into the original Canvas
• Plug it in and see how the C# component only takes a fraction of the previous elapsed time

It seems that the Populate Geometry can create points with very high precision and that is the main cause of slowness. If you deconstruct the points and construct again into points but round the coordinates to something like 10 or 11 digits, it also results in a fast computation.

ConvexHull3dRhinoCommon_internalizedPoints.gh (59.1 KB)

[MathiasFuchs_McN (Mathias Fuchs)]

Good to hear you don’t get the invalid mesh anymore. Please be aware that it is a randomized incremental algorithm (https://ics.uci.edu/~eppstein/164/lecture8.pdf), so one can’t expect GH files to be reproducible. Per performance: that is also very important, but a different problem than “invalid mesh”. I hope I’ll be able to work more on the convex hull to improve its performance.

[AndersDeleuran]

I’ve suggested this before, but it might be worth looking at MIConvexHull for inspiration:

ConvexHull3dRhinoCommon_internalizedPoints_MIConvexHull_Anders.gh (61.2 KB)

[TuomasLehtonen]

I understand. It’s just that both point lists should yield the same result in the same amount of time, now there’s a huge difference. At least I think they should since using the Set Difference the point lists seem equal.

Or do you mean that if I have two point containers in Grasshopper with identical points (at least nearly equal by their first 11 digits), they should not yield the same result due to the algorithm being based on a randomized approach?