Grasshopper Style - Efficiency, File speed & size

Hello,

I made myself a pretty light Grasshopper Style of Shutters with blinds. I am designing a facade where shutters make a big role and wanted to test how it will look in the realistic scenario when different shutters may be set different (fully closed, fully opened, partially opened, etc.), more of, there are different sizes and number of panels - in short: a lot of variations of the same Grasshopper Style.

This of course made my file size skyrocketed by instantaneous addition of a couple of hundred MB… Shutters aren’t any complicated geometry but they consist of a lot of repetitive elements - extrusions of the blinds.
From what I see, when every instance shares the same parameters, file size is under control - this leads me to test Save Small option.

Test file - many copies of 3 variants of the same Grasshopper Style - saved with regular “Save” command - 122 MB

Test file - many copies of 3 variants of the same Grasshopper Style - saved as “Save Small” - 2 MB

In the test file, Save Small made a huge difference in File size and Saving time, but it is a very simplified scenario.

In real-life - Save Small of 80 shutters with different parameters still gives me a 126 MB file.
- After exploding everything to native Rhino elements it grows to 250 MB
- Baking 16 992 polysurfaces into Revit (by Add Brep DirectShape) produces 17,5 MB rvt file. - but that’s just a fun fact, not fair comparsion.

Even a simple Shutter with blinds will have many Blinds (Breps).
I had an idea, that it can be solved by making every blind as a Block Definition and made my definition in a way that every blind would be a non-uniformly scaled Block Instance, but using Block Instances as an output of Grasshopper Style isn’t possible.

Test file which I failed to load as Grasshopper Style

Conclusion:

  1. Would it be possible to use Block Instances inside Grasshopper Styles?

  2. Would the use of Block Instances for repetitive geometries inside Grasshopper Styles provide display speed boost and decrease file sizes?

  3. Are there any techniques that one should follow when making Grasshopper Styles that may help keep Rhino performance reasonable?

2 Likes

Hi @Czaja,

Another problem is that Grasshopper does not work with extrusions, so each object is a polysurface, which consumes much more memory, and it’s a little slower to draw.

Yes, this feature is planned for VisualARQ 3. I’ve added a vote to this entry, so you’ll be notified when we implement it.

Block instances will not make any difference in display speed, because display speed depends on the number of primitive objects drawn (extrusions, polysurfaces, curves, etc.), no matter if those objects come from blocks or model geometry.

File size will be smaller, as block instances require much less disk space.

I guess that the same techniques that normal Rhino geometry. A Grasshopper style will just use the definition to create the geometry. Once the geometry has been created and added to the document, it’s just like regular geometry created by a user.

Enric

Hi @Czaja I’d like to update you with this request. In VisualARQ 3 it is still not possible to use block instances as Input or output parameters in the Grasshopper styles. However, you can retrieve block definitions by Name in the Grasshopper file, get its geometry, and connect it to a Geometry Param as Output parameter in the Grasshopper file.

2 Likes