Grasshopper surface subtraction - 2 questions

Grasshopper
1

Im working on a 3D model of a golf putter.

image
image1178×848 146 KB

All good until i started to substract the ball surfaces from a lofted surface hit area. Then GH is down on it’s knees. 10-20 minutes to solve the solid substraction opf 200 balls from the front face. I tried putting simpler substractions ahead of the ball patterns but and its all becoming 20-30 minutes for GH to compute. I tried to change the ball substraction from the more complex club shape (insert plate in front face)… same horrible time waiting…

Another issue i found is that if you disable/enable a component, the computed values are re-evalued (for 15minutes) despite no changes in the GH model. making matters worse…

Meanwhile what REALLY puzzles me, is that my PC speakers are not grazzing with CPU or GPU chatter like when i mine crypto using CPU (the worst) or GPU (bad but still very noticeable). Noise is not the issue (my 5th PC build with equal issues despite all the noise cancelling gizmos you can find). And if i launch 7 days to die - it’s amazing how switches from one to the other static noise. A good stress game for this…

So what is GH doing??? Waiting? Using the Rhino3D full render also increases the static noise. But GH, nothing.

Sorry if this is a weird way to present a suspect problem… Any explanations?

But CPU is mostly underused from what i see… And these are parallel-able operations 100% right? Subtract a 20*50 pattern of non-intersecting balls off a surface definitely should be. I didn’t write GH, i have no idea.

image
image1490×663 40 KB

What is the optimal way (computing/wait - time wise) to create a surface and substract n+1 sequential surfaces of it? Im only half way down the design and it’s taking now 2 hours or crash to do any operations…

Group substractions for a one off operation? bake and add another step seems inneficient…

Unlike sculpting out features off a block which makes it lighter this goes the opposite way.

Why must each feature take log time longer to work? Last model crashed rhino and we’re talking seriously simple surface substractions IMOHO.

Is there ANYthing i can do to make this work like one would expect it to?

TIA for any hints.

I can’t even provide the last version of the model because it’s still computing 3 hours after i open the model recovery… And we’re talking less than 200 modules in there without serious complications. Not even the screw of the shaft into the putter head…

thanks for any help

2

managed to quit both instances of the putter computation and disabled the buggers…

Here’s the file…
Putter crasher.gh (58.1 KB)

3

missing

4

yes well you have do deal with a few ‘human’ modules in GH to get fonts and list menu item selectors to this work out… I cant type your font names for you…

5

Hah!!! :rofl:

6

to make this simpler, the file i provided should ( can’t check) remove the 200+ balls from a ‘cube’ instead of the lofted club design. So it should be so much faster but didn’t help.

I will try to provide an optimized model asap.

7

To check the code without the long delay, the first thing I would do is reduce the number of balls from 200+ to ten.

8

agreed, but not realistic…what happens later when i try to carve my logo in the club surface?
And then different club profiles (xy plane) to avoid grabbing on the green surface… common issue with squared profiled clubs… Im sure this happens to boat profiles as well… Do you see where im going to? Each carved out edition of this club is going log time longer to compute. Something seems wrong…

9

To verify the code, it is a very realistic and practical step. The code might not be correct or maybe it could be optimized. That work needs to be correct with ten before increasing to 200+.

10

im a hardliner… i go to the limit first then see how it can be optimized…
This is where the issue comes from

image
image1198×552 47.1 KB

11

I know i should have capped before the surface diference but that makes it worse…

12

Wrong approach! But here is a demo of SDiff using 225 “balls” (spheres) that takes only 6.8 seconds, so yeah, there’s probably something wrong in your code.

putter_2021_Jul5a
putter_2021_Jul5a1326×442 147 KB

putter_2021_Jul5a.gh (7.1 KB)

1 Like
13

how is that more efficient from what i do? The subtract module is still the bottleneck… Add a secondary subtract and your toast like me…

14

Show me! (you do it)

If you change the sphere radius from 0.5 to 0.75, the spheres intersect each other and it takes much longer; 33 seconds instead of ~6 seconds. That’s still a long way from toast.

15

Thanks Joseph for you input. But let’s be clear, there are no intersections in the spheres volumes. They are not insersecting.

I separated the difference of surfaces from lofted putter shape to a simpler metal extruded rectangular insert. So how can this be such a hard to compute solution?

16

15 posts into this thread and you still haven’t produced a GH file I can see? :man_shrugging:

17

1 issue is balls subtracted off the insert plate - that’s ‘only’ 200 spheres… I understand that’s harder to compute. Not being silly here.

2021-07-04 22_00_38-Rhinoceros 7 Commercial - Perspective
2021-07-04 22_00_38-Rhinoceros 7 Commercial - Perspective1224×816 305 KB

I wanted to remove the y axis pipes from the main putte block before doing the 200 ball subtract operation but then decided to separate those to their own. Just that this made is kind of didn’t help at all in term of performance solving the design computation time.

18

I think you are, by not producing code that demonstrates the issue (without plugins!).

Hard headed in my humble opinion. Adios. :sunglasses:

19

adios amigo que no ayuda - no hay perdida ninguna :slight_smile:

Is there any way even c# or via python to speed up added surface differences on a volume?

20

Translation: “goodbye friend who does not help - there is no loss at all”

I produced code that demonstrates SDiff of 225 spheres in six seconds. You showed me nothing. I’ll put you on ignore so it never happens again. Bye-bye.