The situation:
I have a set of mesh pipes (generated with NGonGh.MeshPipe) that are mostly inside another mesh volume. Within a Grasshopper Python node I try to calculate the intersection (NGonGh.MeshBoolean([pipe, clippingVolume], 2, False)) of each pipe-object from (B) with mesh (A), to clip the pipes to the extent of A.
The result is shown in C. For most pipes the operation works as expected, but some pipes are completely missing after the intersection operation. The Python Node shows the following warnings:
NGonGh.MeshBoolean: solver component. error: Solution exception:Eine externe Komponente hat eine Ausnahme ausgelöst. (Translation of german part: An external component raised an exeption)
NGonGh.MeshBoolean: solver component. error: Solution exception:Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt. (Translation of german part: The object reference has not been set to an object instance)
If I set the LIBGAL or CGAL option of MeshBoolean to True, the results are a little better sometimes, but there are also pipes missing and the process is very slow (multiple minutes for the data shown).
All the meshes are closed and valid to my knowledge.
The Volume-Mesh and the grouped pipes are attached.
Is there something wrong with my data, or anything I can do to make the boolean operation work more predictable / robust? data.3dm (1.1 MB)
We are still working on MeshBoolean* commands so unfortunately I don’t have a Rhino-based solution. I tried nevertheless to open your file, and noted that the violet pipes are actually a group of self-intersecting meshes. To improve the outcome, I’d try to first make that group a real mesh, by Boolean-unioning all the violet entities. I’m confident that it will help the proceeding of the algorithms downstream.
Also, I tried MeshSplit, selecting all meshes, and using all meshes as splitters. You can use the new-in-Rhino-7 PermitSplittingInputsWithEachOther option for that, available when MeshSplit-ting more than one mesh. That splits quite well, but it’s hard to select what needs to be kept and what should go away. Luckily we started working on this command set!
For now, I think improving the violet curves will help. Also, always analyze the meshes with MeshRepair, which has improved in V7 and even a little bit more in Rhino WIP.
I think the problem is that you have invalid meshes because they are self-intersecting.
Normally it should not work, because in CGAL I am checking if meshes are self-intersecting, then stop boolean operation.
Hi @Petras_Vestartas , thanks for your reply! The self intersections seem to occur, when my curves for piping contain a too tight turn. Is there a way to enforce the pipe output to create meshes or breps with no self-intersections, or is there an alternative for creating solids around a curve?
Yes, one way could be to control the discretization of the curve so that the segments are long enough, then use MultiPipe (you can connect the output to a Mesh Parameter to cast it to a mesh instead of a SubD). curve_polyline.gh (11.7 KB)
The curves could still get close together at other points though, and this can’t be solved just by the discretization.
As Petras says you could use isosurfacing like Dendro to avoid this. You might end up with a fairly heavy mesh, but it’s tricky to solve any other way.
Thank you @Petras_Vestartas and @DanielPiker for your suggestions. I will try using Dendro for creating the pipes and the intersection operation itself. I’m not sure why I didn’t test this already, but I remember having some difficulties with Dendros boolean operations in the past.
Found this thread and works great with the grasshopper script. However, is there a way to adjust the starting and end thickness of the created pipe? Like, to make it start thin, then it continually gets thicker and then thin again? I’m a real grasshopper noob…
