Grasshopper

algorithmic modeling for Rhino

A while back, I posted a discussion that suggested some user interface improvements that use some of the functionality found in 3ds Max Design's Slate Materials Editor. It was a very interesting discussion that I learned a lot from:

http://www.grasshopper3d.com/forum/topics/grasshopper-vs-3ds-max-de...

Today I attended a webinar titled, Vasari Talk Session 22: AU2012 Sneak Peak, that had a section devoted to Dynamo, the visual programming interface for Vasari and Revit. It is very similar to Grasshopper. It should be posted online soon:

http://wikihelp.autodesk.com/Vasari/enu/Community/Tutorials/Vasari_...

What really struck me as powerful was the ability to browse to an external script file and bring it into Dynamo for editing on the fly. It made me wonder if the opposite scenario was possible.

I use CAM software that creates tool paths for CNC machining. When I'm done with the tool paths, I post process it into a simple text file of G code that the CNC machine reads. The software automatically converts the graphic representation of the tool path into simple code.

Would it be possible to post process the results of a Grasshopper definition into Python code that could then be used elsewhere?

This would allow you to use the visual programming interface of Grasshopper to create a complex element and then have the software convert it into Python code. You could leverage the easier Grasshopper interface to create complex scripts that a novice scripter might not otherwise be able to create.

Please excuse my ignorance if this is already possible to do with Grasshopper!

Views: 2834

Replies to This Discussion

Hi Mark,

this comes up from time to time, but I'm afraid it's not really within the realm of possibility. There are two basic reasons for this

  1. Grasshopper uses the Rhino SDK for a lot of geometry processing, and the only way to leverage these features is to run inside of Rhino. So whatever script ends up being created will still be tied to Rhino.exe
  2. It is not possible to figure out what code a component represents. Components are compiled and sometimes obfuscated meaning that their internal logic cannot be properly extracted.

There are also other reasons that would make this an exercise in frustration, amongst the most important:

  1. There is a lot of code that runs in between components. Converting data from one type to another, iterating over items, lists and trees within components, applying expressions and other effects such as flattening, grafting, reversing and so on. All this code is extremely boring but very necessary and there's a boatload of it. Including all this into textual source would render the result unreadable, uneditable and undebuggable.
  2. Sometimes simple components have a surprising amount of code behind them. Take addition for example. It operates on several different data types (integers, floats, vectors, points, colours, complex numbers) and of course also combinations of different types. Sometimes data needs to be converted into other data before addition becomes possible, sometimes addition makes no sense. If you use the Addition component, the resulting code would not look like 'A + B', it would be several hundred lines of switch statements and special case handling.

All this being said, there have been some people who have actually written -albeit very limited- converters from GH to TextSource. I do not know whether anything was ever publicly released though.

--

David Rutten

david@mcneel.com

Poprad, Slovakia

Hi David,

Thank you for your prompt and very detailed response!

I suspected that the Rhino-specific stuff might prove to be an issue but I had no idea that each component had so much code embedded into them. It makes sense though, considering the fact that each component must be flexible enough to work with a multitude of other components which in turn have numerous options within themselves that must be accounted for.

Oh well, so much for that idea!

I do recommend the Vasari video hyper-linked above. I think similar functionality could be added to GH as well. They have a component (they call them nodes) that has a browse button on it. You click this button, navigate to an external file of code, open it in a panel-like node and then edit it on the fly. The results are dynamically updated in the model in real time.

Thanks again for your feedback.

Mark

"They have a component (they call them nodes) that has a browse button on it. You click this button, navigate to an external file of code, open it in a panel-like node and then edit it on the fly."

I'm not a 100% certain about this, but I'm fairly sure that this workflow can be performed using the Python component. Either by reading an external text file containing the code and passing that along to the "code" parameter of the Python component, or, by importing (in the script header) an external module and having the solution update if this module is changed.

Hi Anders,

Thank you for the suggestion about the Python component. As it turns out, I recently attended a webinar about this:

http://modelab.nu/?p=7248

 

The workflow was very similar to the Dynamo workflow described above, but you didn't browse to the external file in the same way. The Dynamo technique seemed more like xrefing the script into the definition, to borrow an AutoCAD term.

 

The webinar was just an introduction to the Python component, so what you're describing could certainly be possible for all I know. I'll have to look into it further.

 

Thanks again for your suggestion.

Mark

Hi Mark, looks like a nice webinar!

Out of curiosity I just ran a quick test to see how this might work (see the attached files, using GH 0.8.00.66 and GhPython 0.5.0.0). Regarding picking/browsing to a code file, I think that a reasonable workaround is to use a "path parameter" in combination with a "Read File" component (remember to set "Read individual lines" to False). This way one may right-click the path parameter and hit "Set one file path" which opens up a browser window from which one can select a code file to read. Here's a screenshot:


Attachments:

Hi Anders,

Thank you for the GH definition with the browse to file workaround. Maybe David can streamline this workaround into a new Browse component for a future build of GH.

 

It was a good webinar. I highly recommend anything that modeLab produces. I attended the Parametric Design workshop at TEX-FAB 3.0 this last April and discovered that Gil Akos and Ronnie Parsons are excellent instructors!

This may not be what you're after, but I wanted to also point out that you can "XREF" entire grasshopper definitions into one another by saving them as .ghcluster files. A saved cluster can be brought into other definitions, and will remain dynamically linked to that saved file. 

Hi Andrew,

 

Very cool! I wasn't aware of that functionality. Thanks for the tip.

hi andrew, i see that option but how do you reference a cluster back in to a new document?

The only way I am aware of is to drag and drop the .ghcluster file onto your canvas. 

Sounds like a good idea, I could imagine such a component being useful in many situations beyond what we are discussing here.

FYI, there seems to be some issues with the latest GH + GhPython component with regards to the "Code" input parameter. I have logged these bugs over on the RhinoPython forum.

Very interesting.
How did you create the "code" input on Python component? I am confused as it looks kinda special - right clicking on it, does not open a regular input context menu, where inputs type could be defined. But rather a shorter one:

?
Thank you for the reply.

RSS

About

Translate

Search

Videos

  • Add Videos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service