Help creating a smart loop for repetitive solid unions

I have an array of spheres along a spline, in an attempt to create a twisted solid shape that does not intersect itself (like it would if it were piped).

I have created a loop to do this (using anenome), but at least one solid union within the loop will invariably fail, causing everything that preceded it to be deleted. Is there any way to alter my code such that, if one union fails, it merely skips it rather than deleting the solid shape that has been created? This has me scratching my head

Attachments:

Curvey Shape.3dm, 1.1 MB
Boolean Union Loop.gh, 14 KB

Replies to This Discussion

Permalink Reply by Mateusz Zwierzycki on February 18, 2016 at 4:34pm

DataTree = SortedList(of GH_Path, List(of Object))... there is nothing magical about data trees and they're not as bad as you think.

Permalink Reply by Daniel González Abalde on February 18, 2016 at 6:18pm

Wow,
you're letting your frustration explode without any respect.

Datatrees are not a list of lists, they are a topological collection of lists. Are the difference between elegance and scribbles in gh (being elegance do more with less). Of course there are better collections, but as a simple and generic structure works well for grasshopper. Once you understand what they are and how they work, you will notice that they have a much lower level of abstraction than it seems when you try to learn it.

Why do you throw shit on something you do not understand? :/

Permalink Reply by Mateusz Zwierzycki on February 19, 2016 at 2:35pm

Hah, I think I got misunderstood here. By saying "there is nothing magical" I mean that data trees are not any kind of illogical black box. They're perfectly fine and serve their purpose. I'm also the very last to be frustrated with them. My impression from Nik's post was that he finds data trees super obscure, while in the principle they ARE SortedList(of GH_Path, List(of Object)) collection. I just found this fact super helpful in understanding Data Trees, hence sharing it below a comment saying that Data Trees are obscure.

but as a simple and generic structure works well for grasshopper.

Generic - yes, simple - not as such, but truly simple to use in the end.

Of course there are better collections

Why better ? I think different kinds of collections serve different purposes, it's usually like comparing apples vs oranges.

Permalink Reply by Daniel González Abalde on February 19, 2016 at 3:52pm

Mateusz my response was to a comment of Nik which has been eliminated, he said datatrees were a meaningless garbage with very bad manners. Without more, I agree with what you say.

Permalink Reply by Mateusz Zwierzycki on February 19, 2016 at 4:09pm

Lol :) That's why I couldn't connect all the dots in this discussion. Cheers.

EDIT: But to be fair, I can understand negative opinions about data trees expressed by other users. I found myself using scripts to manipulate trees way to often (maybe it's out of my laziness, maybe it's just the high complexity of my defs (no bragging here))... While it's easy to criticise, I have no better solution in my mind which could make data manipulation better/more accessible.

EDITEDIT: @Anyone-judging-other-ppl-work (especially data trees). Note that this forum was an origin of many features which are currently implemented in Grasshopper. What I want to say is that we've discussed data trees logic and how this collection should behave here for years, together with many different people. It's not like David is some (he is not) crazy guy inventing square wheels - for instance - the "Principal" param property was conceived as a result of one of the discussions. Data tree matching was also changed quite drastically few years (?) ago after some major release, as an effect of discussions here. In the end - sure, criticise as much as you can but try to provide some examples and/or solutions to your particular problems with data trees.

Permalink Reply by Mateusz Zwierzycki on February 19, 2016 at 2:56pm

But the Milkbox group (http://www.grasshopper3d.com/group/milkbox ) lacks one core feature: a "click to submit" button.

Missed this one. As far as my memory gets, this forum was always intended for sharing, not judging (which is somehow implied by the submit button). Milkbox was intended as a place to share snippets and tools which might be useful for other people. There are not that many discussions there to perform any kind of purge, but once you become a contributor, you have a full access to everything there, you can always take a task to eliminate not-really-that-useful code by talking with the authors.

EDIT: I'm having problems categorizing any of the discussions there as not-really-that-useful.

Permalink Reply by peter fotiadis on February 20, 2016 at 11:44am

You need CUDA stuff not that E5 + 666 cores thingy.

Permalink Reply by Nik Willmore on February 21, 2016 at 1:35am

NVIDIA indeed has some Python links:

https://www.google.com/search?client=safari&rls=X&q=cuda%20...

I wonder if it will work with IronPython 2.7 that Rhino/Grasshopper is stuck with? And it sounds like it's compiled first, so any calls to Rhinocommon that are not actually Python may not work at all.

Plenty of gamers have expense NVIDIA graphics cards.

Permalink Reply by peter fotiadis on February 21, 2016 at 2:46am

Games? who gives a #^%#^5 about these things ?.

See and enjoy:

http://www.nvidia.com/object/gpu-applications.html

BTW: Find a friend who knows CATIA/NX and has some CUDA Quadros on hand > you wouldn't believe your eyes.

Permalink Reply by Anders Holden Deleuran on February 19, 2016 at 2:24am

Hi Max, I noticed that you never state precisely what the output of your definition should be (or where it's going after you perform the boolean union). If you're okay with outputting meshes, it's my experience that performing these massive booleans using these can be both faster and more predictable than with BREPs. See attached file for a simple example.

(Another approach entirely would be to use isosurfacing with Cocoon, but that of course does not provide you with the sharp creases).

Attachments:

160219_MeshBallsBooleanUnion.gh, 26 KB

Permalink Reply by Max Alexander on February 19, 2016 at 2:32am

Hi Anders, I appreciate the input. We had a similar discussion here. Unfortunately for my purposes I cannot utilise a mesh output, so massive brep booleans has been the only way to get what I want. I have ended up using a combination of this sphere array method, and this

Permalink Reply by Anders Holden Deleuran on February 19, 2016 at 2:40am

Well in that case, breps it is. I was thinking that a lighter method might be to make a pipe, find the self-intersections of this pipe and then use these curves to trim the pipe. Unfortunately I don't think that RhinoCommon has a method which finds self-intersections for Breps or surfaces. Hmm, it probably should though. Anywho, best of luck with your project. Looks interesting.

Edit: That's pretty much what you're talking about in the other thread. Apologies ;)