… also known as magic Grasshopper ESP.

There are many times that you might encounter a need to pass data from one node in Grasshopper to another one and it might not make sense to be pulling strings between nodes all over the definition. Personally, I find it much easier to understand a definition when it’s clean labeled and doesn’t have a rat’s nest worth of wires all over the place that distract me and get in the way when I’m trying to make changes, so when it came time to write the nodes for the Gerilla plugin’s library components passing public variables around in the background seemed like the ideal way to do it. For those that aren’t familiar, Gerilla is a plugin that I’ve been developing with my classmates Drew Orvieto and Ben Silverman at the Product Architecture Lab, which will allow Grasshopper to interface with Energy Plus for full building energy modeling. It’s a work in progress right now, but please feel free to reach out to us if you’re interested in wrestling the Gerilla.

In the case of Gerilla, the data that we were passing from node to node had to do with the Project Setup Node and Gerilla’s Material and Assembly Libraries:

Gerilla's Project Setup Node

When a user starts a new Gerilla file they must first setup a new Gerilla project to house all of their assorted Gerilla and Energy Plus info. Custom Project Materials, Assemblies, Simulation Results – all this data will be housed in the project folder.

Since we don’t want to have our files dumping into any old folder in Windows we want to specify a project file path, a project name, and we then want to share that data with the other nodes in the Grasshopper definition (specifically the Project Library related nodes, but we’ll get to them a little later).

The first thing you will need to do is get your project setup in VB.net the way you would setup any other Grasshopper project. Check out the Grasshopper SDK for info on all that.

(A little background info: I’m using SharpDevelop for writing my code, but this procedure should be the same regardless of what software you’re writing in. If you run into problems using some other software let me know – I’d be happy to take a look).

 Public Class GerillaProjectSetup Inherits GH_Component 
'Constructors 
Public Shared PublicProjectName As String = Nothing 
Public Shared PublicProjectFilePath As String = Nothing 
Public Shared PublicProjectLocation As String = Nothing 

So this may seem pretty obvious to you if you’re a little familiar to VB.net. The above code snippet tells us that in the Public Class called “GerillaProjectSetup” we’re making the three constructors (PublicProjectName, PublicProjectFilePath, and PublicProjectLocation) public variables that the rest of our project can read. Easy enough.

The little trick with this is on the other end of things where we want to read the Public Variables that we just made. Enter Gerilla’s Material Maker…

Gerilla's Material Maker

The way that Gerilla’s Material Maker works is that a user will input all of the parameters that a particular material in their energy model has. That material can then be saved to two libraries on the user’s hard drive – the first is the Gerilla plugin’s library, which stores materials that the user wants to have available in other projects and grasshopper definitions. The file path for that library is hard-coded and is set by Gerilla. The other folder is where the user will save the materials that are unique to the particular project that they are working on and, you guessed it, is located in the project directory that is specified in the Project Info Node.

For the Material Node to read the Project File Path from the Project Info node we have to call the variable this way:

 Dim ProjectFilePath As String = (GerillaProjectSetup.PublicProjectFilePath & "\" & GerillaProjectSetup.PublicProjectName & "\Materials") 

The important part of this is to remember to reference the variable as “GerillaProjectSetup.PublicProjectFilePath”. In the above case we got a little fancier and concatenated the “PublicProjectFilePath” variable together with the “PublicProjectName” and a string value “\Materials” to tell the system to save the material being created to a particular folder on the user’s hard drive. In subsequent nodes we can again reference these values to tell Grasshopper to go to that folder and read the material so that the user can use it in an assembly.

So there you have it. Simple and kind of obvious, but I know that there are definitely some people out there that are hunting around for this info like I was and hopefully this will save you some hunting time.

Happy coding.

Mike