What is the Grasshopper geometry limit?


I’m generating a huge amount of geometries (i.e. Rhino.Geometry.Line) with a Python script and Rhino crashes at about 15 000 lines. Is this the limit? Is there a way to spawn even more lines?

Here’s a script generating a million lines. Works fine. Not fast mind you, the viewport refresh speed is about 12 frames per second, but it doesn’t crash.

What exactly does “crash” mean in your case? Error message? Sudden shutdown? Frozen UI?

1 Like

Sudden shutdown! The Python script runs like a counter and produces 35 lines per iteration (component refresh) that are saved within a class object that is saved inside the sticky dictionary. It stops when a certain goal is reached and works great for less dense examples.

Any ideas, @DavidRutten? How can I see the Rhino error log (on macOS)?

I don’t think there’s an error log, if Rhino crashes (at least on Windows) it tries to collect as much data as possible and send it to us as a report, but that involves a window with an OK button on your end first.

One situation in which this doesn’t happen is with certain out-of-memory errors, such as stack overflows. But being neither a python nor a Mac expert (or even user) I am afraid I’ve reached the limit of my usefulness in this case.

1 Like

Outputting that much data is a likely bottleneck (i.e. not generating them). See this old thread for a bunch of methods for circumventing this issue:


Assuming that you are indeed outputting the lines, that is. Remember to provide an example file :wink:

1 Like

OK, thanks anyway! Right after the sudden shutdown, a notification from Rhino appears in the macOS Finder (desktop) that states that an error report will be available in a couple of minutes.
After that nothing seems to happen and I have no idea where it is located though.

I’ve monitored the memory usage and a little over half of my system memory is free, when Rhino crashes/shuts down. Is there a limit of memory available to Rhino?

Thanks, I’ll check this out!

I use the recompute method that you kindly posted some time ago! The one that makes the GHPython component recompute like a flexible, internal counter.
As mentioned above, my script produces a single class object that also stores all necessary information, including the lines list. To survive the component re-computation, it is at each iteration saved/overwritten in the sticky dictionary. Nothing is else is stored there.
And yes, the lines are also output at each generation through the output a of the component. The lines are Rhino.Geometry.Line() objects!
I can’t share the script sorry. It’s work-related, part of a competition, and thus must be treated confidentially.
If you have anymore tricks up your sleeve, they’d be super appreciated, @AndersDeleuran! :slight_smile:

You can try to wrap them in Grasshopper.Kernel.Types.GH_Line(). This can substantially speed things up when outputting RhinoCommon geometry types. I’m not sure it’ll do much with a line though, but worth a shot.

As discussed in the old thread above, wrapping the data in e.g. an outer list or a dictionary is an almost cost-free and neat (some might say hacky) method of sending large amounts of data through Grasshopper wires from one GHPython component to the next. This of course won’t work if you need to do something with the data on the canvas.

Although I wouldn’t think so, iteratively writing to sticky might also be a bottleneck. I’d suggest using the if "foo" not in globals() method of creating a persistent variable, again if possible.

1 Like

@dan do you know whether and how this works?

1 Like

It’s not as simple as that. The memory which runs out may just be a small corner of your RAM reserved for a specific thing like the call-stack or GDI handles. The fact that there’s memory unused elsewhere doesn’t really help.

1 Like

Thanks, Anders!
Yes, I know about this, but I’m getting the lines by “extracting” mesh edges by index. Would it still be beneficial to do this?

What I’ve tried so far from your other thread is not outputting the lines at each frame/iteration. This immensely speeds up the refresh rate, but Rhino still shuts down at about 15K line objects, now only faster! :wink:
I thus think that the re-computation isn’t the source of the crash, since it stays constant at 20 to 40ms per iteration, which doesn’t seem that bad! The crash must be caused by data accumulation somehow.

You might be right about the sticky, but I don’t know how to test this theory!
I’m not familiar with persistent variables! Do these survive re-computation?
How do I declare one in order to store my class object?

This is the notification I get:

Thanks for explaining this. I’m no expert in these matters (yet). :wink:

That shouldn’t matter. A Rhino.Geometry.Line is a Rhino.Geometry.Line right. And indeed, wrapping these in a Grasshopper line type does appear to speed things up, but not as substantial as with more complex geometry types:

191120_GHPython_WrapOutputInGHTypes.gh (12.8 KB)

This does sound more like a memory leak-type issue to me as well.

Have a look here:


Thanks for all the help, Anders and David!

This might be slightly tangential to the discussion, but…

Yes. It ought to work in principle, but I have seen situations where it does not work in practice.

When Rhino for Mac (Rhinoceros.app) launches, it also launches a separate app - called RhinoMonitor.app - that watches for crashes. When Rhinoceros.app crashes, it writes a crash log to a standard macOS location using the macOS Frameworks. At this point, the process is typically out of the application’s hands (it already crashed after all). Sometimes macOS writes the log, sometimes it fails for [unknown reasons] or takes an insanely long time to write the log.

RhinoMonitor.app watches for new error/crash logs and kicks into gear. If it doesn’t see a crash log in a reasonable period of time, RhinoMonitor.app terminates itself.

Ok, maybe that’s TMI, but that’s how it “works” when it works.


How can I see the Rhino error log (on macOS)?

If the log is still here (presuming macOS wrote the log), you could also check using macOS’s built-in /Applications/Utilities/Console.app. You have to filter stuff a bit though…

1 Like

Hm, doesn’t seem like there are any crash reports.