Export .SKP From GH?

[ed.p.may]

I’ve had really good luck lately exporting Rhino geometry to Sketchup (I have to so I can pass along to another team who are required to use Sketchup). I’ve been using the ‘Rhino’ grasshopper components to build up blocks, and then export those which come into Sketchup well structured and nicely tagged. But, this workflow requires that I bake to the rhino scene and then manually File/Export… everytime.

I wondering if anyone knows of a solution for exporting Sketchup .skp files from directly within Grasshopper instead? Are there any example scripts or plugins that do this sort of thing that work well?

Environment:

• MacOS Sequoia 15.6
• Rhino Version 8 (8.25.25302.09532, 2025-10-29)

Any references or things to take a look at are much appreciated.
thanks!
@ed.p.may

[scottd (Scott Davidson)]

Use the Export Block definition as a way to collect up the objects and then export to .SKP

This post may help: Export Mesh as STL-File - #14 by scottd

[ed.p.may]

Thanks @scottd ! Very cool and very close, but it seems like exporting the block-definitions this way gives me a different .SKP file structure than when I export the block-instances using Rhino’s File/Export…

---

Grasshopper Export Block Definition:

results in a Sketchup file that opens like:

with ungrouped geometry, and for some reason only one definition comes though.

---

Rhino File/Export…:

First, bake the instance geometry back to Rhino,

Then File/Export… yields a SKP file structured like:

with geometry faces and edges nicely bundled into a component. In this case, both instances come through.

---

Example File:

example.gh (12.6 KB)

think its possible to make that GH exporter work this way? Thats exactly the component I was looking for, but the behavior isn’t quite the same as file/export…

thanks!
@ed.p.may

[scottd (Scott Davidson)]

Just one more block definition needed. The best way to think about it is that the last block definition is acting like a temporary document to hold/collect everything else.

[ed.p.may]

So good! Thanks a million @scottd - this is gonna make things so much easier! love it.
@ed.p.may

[michaelvollrath]

@scottd

The best way to think about it is that the last block definition is acting like a temporary document to hold/collect everything else.

Thank you for providing this solution!

Regarding the need for the last block definition “container”. This feels rather counter intuitive to me, if one has a data tree of block definitions defined in GH and that is an input for the Export component I would expect the output to be a file full of the content of that data tree or, if grafted input potentially even export a single file for each block instance. That could be messy but also very helpful in certain instances.
___

Just my two cents and admittedly I’m currently using it in a pretty specific way for processing large Revit models with RiR GH, organizing, cleaning, and prepping the model geometry and components for more advanced use cases down the road such as embellishing the geometry/materials in third party rendering programs, advanced animation uses, etc.

We get all sorts of varied geometry and conditions from our client’s models and Revit organizes some things well but most things quite poorly.
For example, Revit treats “handedness” of families as a unique block instance when exporting to .DWG, .DXF

Prior to this workflow each “handedness” direction of a component coming from revit would need to be handled twice and then have its duplicates purged. Now we organize our data by the original family geometry, instance it, and then use transforms to account for position, rotation, and “mirroring” aka handedness in Revit.

Thanks for your solution, it allows us to cut out an excessive amount of labor that has just been reserved for “clean up” operations before the design work even begins.