Grasshopper

algorithmic modeling for Rhino

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

Views: 7958

Attachments:

Replies to This Discussion

Though slow to rotate the view of a Grasshopper preview, the baked closed polysurface is usable in Rhino.

So when will Rhino and/or Grasshopper developers generalize this strategy to do parallel processing and add a jostling fix to make the native Booleans actually robust instead of fragile? I can't generalize it for objects in space since I don't have a clue how to arrange the parallel processing in pairs that actually overlap.

At long last, a single parallel processing Python script that loops through cycles of smart (perturbed away from fails) Boolean unions, joining pairs of balls (or other shapes) arrayed in overlapping fashion along a curve, then joining pairs of longer unioned segments until it's all one long millipede.

1200 balls takes 0.88 minutes.

2400 balls takes 2.7 minutes, which is a disappointment versus 1.3 minutes for 12 simple single loop Python scripts arranged in a string on the canvas. I wonder how to find my overhead in there? The slow part is the Booleans really, so how can it be only half as fast just because I'm doing the cycles internally? Should be the same or faster!

Ah, to initialize I'm pretending the original input is the result of yet another Boolean union cycle, but that means I'm running adding index numbers just so I can needlessly sort and then remove them, something I can make a flag to avoid for the first cycle.

That made it slower, 2.9 minutes. That's just not fair. I need to learn to optimize speed but am not sure how to measure it, I guess with time clock commands to see which parts are a slow?

Oh well, here it is for now.

It's a good system actually since only a small number of balls afford a fast preview in only a few seconds:

Attachments:

Python WHILE loops are said to be terribly slow so I pre-calculated the number of cycles to use a FOR loop instead. It hurt slightly instead of helped.

Parallel programs suffer overhead that seems hard to intuit. It should be twice as fast, to match the broken apart program module Grasshopper canvas chain that had no loop inside.

I've added a timer for each program "paragraph" completion, which I can compare to the beads-on-a-string version of separate components.

THE SCRIPT IS JUST FINE, JUST AS FAST AS THE SEPARATE COMPONENT VERSION. I must have made a mistake in remembering a faster time before using a stopwatch.

Here is a nice verbose version then, that seems to work and is as fast as can be since it indeed uses 100% processor power effectively, unlike Anenome using the native Grasshopper Boolean Union component. It uses Rhinocommon for the Boolean, not that same node-in-code Grasshopper, so shouldn't indeed be suffering any buggy slow down as has been reported.

Q.E.D.

Attachments:

Very impressed at all this! I am very grateful for your help Nik, I have ended up doing a combination of this boolean method, and a method similar to what you described here, which made more sense for the less twisted top section.

Thanks!

Benchmark it then! The time though depends on the resolution of the ball method. The key though is to jostle one of the parts of each failed Boolean until it succeeds. Takes usually one step but sometimes up to five.

An old extra line #61 snuck into the final script. The Python editor won't let us close and save without running long scripts once again, so sometimes I close the window using the X box and it fails to update since I seem to ignore the ambiguous apply warning, since no, I don't want to run again, just save.

Just delete line #61 if you already have it.

Attachments:

:D nice!

thanks Nik! amazing work!

you should post this on the milkbox group... or open a "multi core components" group or something like that... 

I'm a chemist. I just call hard work to simplify things "distillation."

Milkbox I see is a library of useful scripts not turned into silly lonely one-off plug-ins that actually require installation which refuse to auto-update. But the Milkbox group ( http://www.grasshopper3d.com/group/milkbox ) lacks one core feature: a "click to submit" button. I dunno! Bye.

I was so utterly horrified by Grasshopper data trees, and the PathMapper, that I learned Python. I think I'm an outsider, thus. Either I trust-fund-a-MENTALLY misunderstand date "trees" (date TREES?!) or else I am coming out on top, actually being able to achieve things since I'm not in some cult of Grasshopper as a difficult computer video game that is obscure on purpose.

RSS

About

Translate

Search

Photos

  • Add Photos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service