algorithmic modeling for Rhino

Hi everyone, 

I have some difficulties with joining a list of closed Breps into a single closed Brep (vase).

I already tried many options using SolidUnion, Join Brep, also Graph/Flattening did not create the desired result. 

Eventually I want to have 1 closed Brep/Solid where the multiple shapes are combined with the vase, to use for 3d printing.

Is there anyone who can help me out?

Thanks in advance!


Views: 378


Reply to This

Replies to This Discussion

At first glance from your png. You should not be grafting the Solid Union input. Everything you want to union should be in one list (flat). Cant tell much more than that without a file and the geometry internalized. 

I'm sorry, I added the gh file. It is quite a large file though..

Bool operations are a tricky B*tch and fail often. However I cannot inspect the definition as the python script is referencing things I don't have (they seem to point to something on your computer)

I suggest baking those geometry made after the pythong and referencing them into the param components you have there after python. Then internalize those geometries (right click on the param components once geometry is referenced and hit internalize) and re upload. Or try Birk's solution to see if his method helps. 

On another irrelevant to the post question note, the definition is quite redundant in copy / pasted components, its not really the best way to take advantage of gh. I suggest thinking about your data a bit more in the data tree aspect. It will make your life (and definition legibility) much simpler the sooner you break that habit of copy pasting singular processes. (I know easier said than done but def beneficial) See example image below of just a small part of your definition that can be easily condensed due to list matching and data trees. Left is from your definition, right is condensed, both output the same result. 

Thank you for the feedback. I am completely new to grasshopper and this is my first big project.. The internalize geometry does not give the desired result unfortunately. 

Hmnn. Internalized is not for you. It's for me :D it is so you can send me the gh file with the geometry saved in the actual gh file. This way I can look at it to help. Right now I can't determine what is wrong because your python component doesn't work on my end.

Internalize will not change the result. Again it is just easier way for you to send the file to me.

You can right-click on the 'Geo' and 'Srf' params after the Python component and click "Internalize data".  The Python output will be saved inside those params and they will be disconnected from the Python component.

This allows the rest of us to see your code working without having our own copies of 'Image file (.bmp)' and 'Potrace file (.exe)' (the inputs for the Python component).

Ah now I understand, thanks for the clear explanation. I attached the updated gh file.  


Yikes!!  I lost track of the total time it took to open that file; close to an hour I guess, based on some readings from the profiler widget - 32 minutes for the final 'SUnion' alone, plus many other components all measured in minutes.

'SUnion' fails in this case because the two wires connected to it create a tree with two branches instead of a single list.

It looks like you're trying to perforate the vase?

Honestly, there are so many problems with this definition that it's hard to know where to start...  Any model that takes that long is too cumbersome to work with.  You could debug the model using only one of the 178 results from 'Cull', then when it's all working. change it back to all 178, knowing the long wait will be worthwhile.

Well he is a beginner. Problems are too be expected, we should keep it positive. Jelle Meerman just take a look at the image I made above about condensing parts of gh workflow. These things will really help you, most specifically understanding how lists work and how to manage them (for instance knowing to flatten into the SUnion) Take a look around at some data trees stuff or in the primer. General rule for me at-least, anytime you find yourself about to copy a part of the definition to repeat a process, stop for a second and think is there a smarter way to pass this data. Copying duplicate processes over and over is sometimes easier but you usually pay for it in the end in terms of legibility and computation time. (It also makes it harder for people to try and help, I'm surprised Joseph had the patience to wait so long for it to open :D)

Thank you for the feedback. I will first try to 'smarten' up the script:)

Thanks for the tip. I first tried to extrude a circle and solid union that one with the vase, as a reference. Which did the job. But when I switched to the 178 solids it didn't work anymore. So I will try a single solid for the list then.

I actually want to merge the solids with the vase (not perforate it)

If you would have noticed my last reply you would have seen that it is not a problem of grasshopper, but rather about the geometry you create.You can boolean-join such  shapes with one click in Rhino, without any need to do this in Grasshopper. However Rhino will also fail. Simply because you cannot join overlapping surfaces like this. I may pissed you off with my last reply, but seriously learn more about nurbs modelling first. If you can do it manually you might be able to automate it. Boolean operations are very well implemented in Rhino, and they are very reliable, as long as you model clean. For those rare case where it fails you can easily tweak it manually. I never made a complex mapping without any need for manual tweaking. So before spending weeks in trying to  automate everything from beginning to end, you better deal with 5-15 minutes of manual work.  





© 2018   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service