Is there a way to speed up GH/Rhino processing?

This image is 151 units high and has 1198 7-sided cutouts in a surface of revolution. I used Rhino Render to make the image, but all I really care about is the time it takes for GH/Rhino to finish processing and display results. This one took slightly more than 30 minutes to generate on my 16GB Win10-64 system running on an i7 CPU and an nVidia GT750 graphics card.

That seems like a long time. I checked CPU usage and it never got much above 15%, even though Resource Monitor said Rhino had 7 tasks running. The CPU line charts showed very sporadic usage of each CPU.

Needless to say what I'd like to do is use GH to change the size, spacing, and shape of the cutouts in real time - but with 30 min. between renders this is not feasible. I make only relatively small parts for 3D printing, and can only imagine how long it might take for a complex architectural model to finish processing.

PS: Many thanks to Daniel González Abalde for showing how to make equally spaced points on a curved 3D surface. I like these much better than the random points I had been using. But I'm keeping both methods just in case.

Attachments:

Capture.JPG, 82 KB

Replies to This Discussion

Permalink Reply by David Rutten on June 11, 2016 at 1:43am

It does seem like a long time, even for a Solid Difference operation like this. They are amongst the slowest of operations though, so if anything is going to make you wait, a solid boolean will. You can try baking the geometry instead and running the Rhino _BooleanDifference command manually to see if it's any faster, at the very least I'd like to know whether it makes a difference.

The only thing that matters in this case is the speed of a single logical core (sometimes called 'thread'). The amount of memory (provided it's sufficient to run the operation in the first place) is irrelevant. The graphics card is irrelevant. The reason you're only seeing a 15% usage is because only 1 (ie. 12.5%) of all your 8 cores is actually doing Rhino work and the remaining percentage points are probably taken up by Windows.

There is nothing you can do to speed that up, except buying a faster CPU (faster per core, not faster overall!), and the i7 is already pretty fast. At any rate, the improvement you'd see would be marginal at best.

Sometimes the other cores can be unlocked with some custom programming, but in this case that won't really be possible either since you are performing a long running operation on a single shape, so there's no way to distribute that to multiple cores.

Permalink Reply by Birk Binnard on June 11, 2016 at 6:18am

Thanks David, I appreciate your response and I understand what you have said. I thought the Boolean subtraction process was behaving like it was single-threaded but I wasn't sure. Thanks for confirming that. And I do know how complicated it can be to transform a single threaded process to a multi-threaded one. Perhaps some day that might happen.

Permalink Reply by David Rutten on June 11, 2016 at 7:36am

It is something we're very focused on for Rhino6, and for things like boolean operations on a single shape it is indeed only the Rhino core developers who could speed things up. On my end I'm trying to make sure that several boolean operation can run in parallel for the next version of GH.

Permalink Reply by Birk Binnard on June 11, 2016 at 8:37am

Excellent news David; thanks. We are all looking forward to what you and the Rhino team come up with next.

Permalink Reply by Daniel González Abalde on June 11, 2016 at 4:57am

If you restart the computer and test again, still it is taking 30 minutes?

There are alternatives for Boolean operations, but may not be useful.
- You could create a polysurface for each Boolean operation to work on one surface, and then put it all together. But in an irregular distribution, this would be difficult/inefficient.
- You could, instead of Boolean difference, trim the stars on the surface (A=surface without stars, B= stars on surface), offset the cut stars (B) and loft the offset with the (A) surface.
- You could make a difference Boolean only once, if you first join all the subtractions in the same solid. But this sounds a little crazy.

By the way, you can use the [Cull Duplicates] component to eliminate points too close (adjusts the tolerance with an appropriate distance).

Permalink Reply by Birk Binnard on June 11, 2016 at 6:25am

Thanks for your suggestions Daniel - that's an approach I had not thought of. It is a bit more complicated that a direct Boolean subtraction, but if it allows real-time updates it will be worth it.

As a self-taught GH user I was not aware of the the ability to adjust the Cull Duplicate tolerance. That will definitely solve my problem of having some cutouts too close together. I never thought about how the basic shape of the part would affect how close or far apart the cutouts woudl be on different areas of the part, but it certainly does. It is interesting to learn about all the inter-relationships geometry can have.

Permalink Reply by Daniel González Abalde on June 11, 2016 at 6:51am

So many boolean differences/cuts are not changeable in real time. In this case, you should settle with the stars (curves) as a preview, make changes and find the parameters that you like, and then make the Boolean difference/or other method. For this you only have to do a gate with a button, for example using [stream gate] and [stream filter] components, and within the entire operation of subtraction. This way you control whether or not to perform an operation of high cost.

Permalink Reply by Birk Binnard on June 11, 2016 at 8:30am

Thanks Daniel, I just recently learned about the stream gate and filter so I will try that out. I already have a way to switch between circles and multi-pointed stars so I am hoping that will help too.

RSS