Grasshopper freezes

Hello,

Grasshopper always freezes on my laptop when the code becomes moderately complex, I had posted regarding this issue a while ago at the time there were issues with my code that likely caused GH to freeze, however the issue has persisted. I do not know if the issue is my code, i have uploaded one of my more recent projects where I believe things should be running smoothly, however rhino stops responding when i try to load it or do any further work. I am using a lenovo legion pro with 13th gen i9, 32gb of RAM and a 4080 graphics card. My computer will only freeze when using GH, there are no issues with other software/games.

Please advise!
panel_for_tio_new.gh (30.5 KB)

Hi @Petros
you are using a couple of obscure plugins, so I cannot comment with absolute certainty (if such a thing even exists).

But even without it, I can see a couple of things…
Especially towards the end you have some super slow boolean methods.


Plus you are calculating the area of a closed solid, in order to get the centroid, which seems to take a long time.

I can imagine that if the size or number of objects increase, the calculation might take several minutes, if not hours.

First of, replace the area calculation with Bbox center (Surface/Analysis/Evaluate box with default settings). You get basically the same point, with ~250 times faster.

Then try to figure a way for you to get the exact shape of the object, without relying on boolean operations.

EDIT: And comes to mind that the reason for the freeze might be in one of these plugins.

Hello Toni, I will look into that. I am still a noob but this is very helpful.

Thank you loads for the help!

I also doesn’t use plugins.
I tried to replace your components and also my gh froze for 1 hour then i killed rhino…

This is fully unrelated by the performance of your machine.
I’m sorry but your definition is bad, and that is making grasshopper freeze.


This is roughly remade with normal components, it compute in some second here.
Final component is disabled.
panel_for_tio_new.gh (30.7 KB)

Problems:

  • you are making a loft of interpolated curves, while this work, it hugely increase the control point count of your result surface. Use instead “Surface from points” component, interpolated.
  • you are making solid booleans between solids that barely touch each-other, this is unwise. Make your “cutting” solids in a way that decently intersect each-other. (avoid having solids A and B from having congruent or tangent faces)
  • on the end of the definition you are scaling a by 0.98 a solid and doing the solid difference with many other solids that are very similar in shape, that obviously result in a really odd shape:

    This last solid difference seems a mistake to me.

Did you do this alone?
Are you trying to replicate a tutorial?
Or are you starting from a picture concept?

Solid boolean operations are tricky, always save before starting a massive one (and in gh this is often), and be ready to kill rhino and retry differently. Don’t waste your time.


PS
grasshopper components preview can be turned off one by one.
Each grasshopper component that might display a mesh (like a surface, brep, subd) will require a “meshing” step (visible also in rhino) before being visible on screen.
If you leave some component with preview disabled, it will spare you some computation time while you change some of the inputs variables of your definition.
This also applies to all gh components as a whole, if you toggle grasshopper preview to wireframe or none. Useful if working with many and/or complex breps.

Honestly im happy its because of my code and not my machine. The first section was copied from a tutorial, (using simplex noise - remap numbers… until the surface is lofted) , I will use the surface from points instead. But other than that section the rest i did myself. Honestly i hadn’t been told anything regarding boolean operations before, so I will keep that in mind going forward. Regarding the scaling by 0.98 I didn’t love my approach, and this wasnt the intended outcome, but GH just froze afterwards, im trying to recreate the design keeping in mind your advise.

Could you siggest alternatives to boolean operations, as you can tell im still a novice. I usually turn off the preview on most of my components while working and only preview what I am currently working on. I will also look through all of my installed plugins to check if they could also be causing some issues.

Thank you for your help!!!

Since you didn’t post a picture or a sketch of what should the final result look like, I have no idea of how to guide you.
I’m not saying you should completely avoid boolean operations, actually there might be no really alternative for cases like yours. We can try to use them wisely/smarter…

I dont have any sketches to show but the back should be flat, this is for a wall panel for a friend of mine. The point is to have two different coloured panels alternating, i will then make each be longer on one side and progressively become shorter so the colour of one can fade into the other. I had created a simpler version but my friend prefered this one so i am trying to make it work. I was thinking to perhaps use dispatch to group the projected curves (two at a time) and loft them with eachother rather than extruding.

I tend to use solid difference in most of my scripts. especially for trimming geometries, Like i did with the initial SD component. would you recomment any alternative components for such uses?

I posted a much earlier version of this concept, obviously I am now trying to have the panels be curved rather than vertical.

Your file seems to work great though, it should be more than enough for me to finish my design.

thank you again

I have done a ton of these…

The simplest way is to have just a surface and then contour it. With the contour curves you can create the 3D by making it a closed crv with a straight backside. No need to boolean at all. Just make sure that the initial surface is the right size.

And once you’re only dealing with curves, it’s easy to distribute them along a curve if you need some shape to the wall.

I am now trying to have the panels be curved rather than vertical.

This one I don’t understand…

1 Like

Well you see how each one of the panels in the photo is vertical, i would instead like for them to be curved, like this if that makes more sense.

Lovely reference by the way.

…so curved in 2 directions?

ok, then, try to build your shapes in a way that the back face is flat, so when you will do later the solid boolean operation Rhino will have to handle simpler geometries.
The way you did, Rhino did find surface intersections between complex surfaces twice the amount you really needed.

Also remember, you can do boolean operations with open breps, or even simple surfaces.


Interesting. Cool.

But how will you manufacture it?
In case of flat panels, if you plan to simply cut it with a 2D machining, doing all this complex solid (3D) operation, is useless. It would be simpler and faster to compute just the sections for each panel and extrude it.
If you plan to make each panel outer shape to be 3D milled, then ok… More complex shape. Solid booleans as you did are required…

No idea of how you will manufacture it, but ok.

@Petros
I did a quick test on your definition, cleaned by @maje90
Now I saw the tween curves there as well.

Not taking in any size or sizing (or fabrication) related issues, but here’s a crack at this curved wave.


panel_for_tio_newnew.gh (38.8 KB)

Yes, ideally the curve will be more curved than that though.

I do not know how to make it flat on one side other than extruding and then cutting it with the boolean difference, I’m sure there are better ways… Well as cool as milling sounds the answer is much simpler, it will be made of polyurethane foam so fabrication will not be an issue.

@Petros
Please check the definition I posted. There’s one option there.

OHHH i see i see, okay that is massively helpful! I will tweak this further hopefully tomorrow, thanks again !

There’s a known issue with area and volume calculations if the shapes are very large or very far away from the origin. Is that the case here?

No, this brep is near origin and the size is near 500 units…
The brep was just ridiculously complex (surfaces with insane amount of control points).