Joining a list of numerous Closed Breps doesn't work

[nicolas.fryder]

Hi,
I have a code in python associated with a few nodes that create a random array of cubes, as you can see on this picture:

(number of cubes and length are small on purpose to keep the file running smoothly

My question is simple: How to effectively join all of these cubes into one voxelized beautiful brep that only keeps the exterior shape?)

No need to get into the nitty gritty of the code which is not effectively written (I’m a beginner it’s awful but it works and I like it), just look at the two nodes that I circled on this screenshot: they both output a list of closed breps. I’d like one mega-giga-ultra big brep perfectly joined.

I tried the Join Brep component, it didn’t work. I tried the Solid Union component, it didn’t work. I tried to fiddle with the size of the cubes (the y slider on the bottom of the file) so that they overlap a bit, it didn’t work either. I’m open to any suggestion in Grasshopper or even in Python !

Thanks a lot !
Projet Grasshopper.gh (12.8 KB)

[RIL (Rolf)]

I didn’t look into your GH file, but I think that what you want is Boolen Union, not “Join” (join connects surface edges and cruves, not solids)

// Rolf

[akilli (Ethan Gross)]

If meshes are good enough for you, you can either generate them in your python code (I don’t know how) or as, I did, convert your cubes to simple meshes and then use Mesh Join and Weld Vertices for a solid. Grasshopper is always iffy when it comes to lots of solid unions, even cubes!. One way around it is to use Anemone and join them sequentially.

Projet Grasshopper2.gh (12.8 KB)

[nicolas.fryder]

@RIL

but I think that what you want is Boolen Union, not “Join”

Thanks for your help, but the BooleanUnion is returning Null (the help for the fonction mentions that it’s supposed to merge surfaces, not breps.) Is that what you meant?

Edit:

@akilli

If meshes are good enough for you, you can either generate them in your python code (I don’t know how) or as, I did, convert your cubes to simple meshes and then use Mesh Join and Weld Vertice s for a solid. Grasshopper is always iffy when it comes to lots of solid unions, even cubes!. One way around it is to use Anemone and join them sequentially.

I tried the second method: i converted the breps in meshes, and used the same plugin as you to join them and weld vertices. Problem is, the result is still a big mesh with a lot of faces and points on the inside. I’d like to get a mesh, brep or surface that is the outer enveloppe of the stack of cubes. Sorry if I wasn’t really obvious tho. That’s why I wanted to “join” breps: to get one large empty brep with the surface aspect of the outer enveloppe of this stack of cube.

I’ll try to do it by iterating the fusion of breps one by one, but I just can’t find a python command. And the ‘Rhino.Geometry’ commands, in C#, only applies for baked geometry rhino, right?

Thanks for all the help

[PeterFotiadis (Pfotiad0)]

Tested your stuff with a C# of mine that always yields results … and it failed. I said: what’s going on here? Then a zoom into your data exposed the truth: your cubes overlap. NEVER do that if you want some decent results (tol is a big issue not to mention that you make life for any Method quite difficult).

Other than that:

1. DO NOT make Breps when boxes is all what you need. P is not my game but I guess that if you do boxes you could enjoy far better elapsed times.
2. For the union job: for more speed convert the boxes to meshes :
   
3. Then things become a bit complicated because the R Method: Mesh.CreateBooleanUnion(mList) works some times and some times it fails (explanations are complex). For instance see these simple cases:

A Method in C# (72/100 ms, all mini meshes appended) :

A Rhino Method (390/470 ms, several mini meshes are MIA):

4. So … try to union your mini meshes one by one and for each step PRIOR the union (BigMesh.Append(miniMesh)) remove the common faces (if they exist). If you do that … results are more than certain (still tol is always an issue in relation with the placement of the mini meshes [with regard word.Origin] … but let’s be optimistic). PS: You can’t auto translate C# to P … but here’s some hints on the logic used:

[akilli (Ethan Gross)]

Here’s another approach, using a subset of your rather large sample: I placed a sphere within each cube so that it just poked through each face,and exploded the faces. Any face that intersected more than one sphere was culled, leaving only those faces on the outside of the model. They were then joined into a closed brep. Might not cover every single case…

Projet Grasshopper try2.gh (15.6 KB)

[beremiz.2000 (Angel)]

I don’t know why, but intersection in a loop maybe works, i had a lot of troubles joining breps, most of them i solved scaling by 1000 joinin, and rescaling again (one more reason for work in milimeters)

[emilio]

Here is a variation of Ethan’s method.

Exploding the breps to get the faces and then keeping only the faces with unique centroids.
That is, if we find two face centroids at the same place, we discard the faces.

Projet Grasshopper B.gh (11.4 KB)

[Birk_Binnard]

Wowee! Many thanks - and a question

I use GH/Rhino to design parts for 3D printing. Many of my designs have “overlapping shells” which in effect are the combination of intersecting Breps. Designs like this are a problem because, for 3D printing, you have to export the final geometry from Rhino as an STL file, and STL files don’t accommodate overlapping shells very well. Actually, not at all.

Here’s an example of apart I’m currently ready to print:

As an exported STL file (or mesh for that matter) this part cannot be printed because the slicing program that generates the printer’s control code misinterprets the overlapping shell geometry and produces bad results. So, to fix this, it is necessary to run the STL file generated by Rhino through a “fix it” program. Fortunately, there are a couple of these that are readily available and the almost always work ok.

But having to do that is annoying and time consuming, and would not be needed of the problems of overlapping shells could be eliminated before creating the STL file. I’ve tried various ways to do this, but none of them worked.

Until now. By simply adding 3 mesh related operations to my final Brep function I get a result that no longer has overlapping shells and whose STL file I can process with no problems:

The SDiff creates the final geometry I want to print - the image shown above - and the 3 mesh functions eliminate the overlapping shells and produce only the “outside” of the part which is exactly what’s needed for 3D printing. The comments by Ethan, Nicolas, and Peter made it clear to me that this is what I should have been doing all along. This simple method will save me a lot of time and CPU cycles - so thanks to everyone for pointing it out.

My question is also simple: why, when I select any of the first three GH components shown above, does my display look like the first image, but when I select the 4th one, it looks like this:

That is the object I bake and export and it produces good results, but on screen it looks - weird. Since it is the final result that counts I’m not all that concerned about this, but it would be nice if the final result looked like the final result.