How the Elefront Plugin Solves the Biggest Problem in Grasshopper
The plugin that turns one a single script into an entire system
Even if you don’t use Grasshopper much, you’ve probably seen a script like this before.
It’s neat (I think) and the colours do help show what each “group” is doing… but the thing is massive.
It’s huge because it’s doing a lot of things at once. It takes geometry from the architects, rationalizes it into structural geometry, applies metadata, pushes the geometry into an analysis program and also pushed the same geometry into Revit.
It’s truly one script to rule them all. It’s amazing.
Well... that is until the client makes a change in the geometry and I have to go diving in this sea of components to find out what went wrong.
I think this is what people mean by finding a needle in a haystack.
As amazing as this script is, all it really takes is one small change to the incoming data or geometry and it will stop working.
But you know, it wasn’t always like this.
When the project first started, this script was small, intentional and quite easy to manage. It was built to help rationalize the client’s geometry.
But because it was valuable, we kept adding more to it. Since we already had the rationalized geometry, it was only a few more steps to push that into the an analysis program. Oh, and since we can already do the analysis model, adding more metadata for a Revit model is only a few more steps again.....
And before you know it, you have this behemoth of a script that is extremely powerful but fragile to any kind of change.
Unsurprisingly, this is actually the usual journey for most computational scripts. You start of solving something small and then you keep tacking on new features or requirements as they come without reconsidering the original design.
There’s an official term for this actually. It’s called scope creep.
Whether it’s a Grasshopper/Dynamo script or a “properly” developed plugin or program, most solutions suffer from scope creep.
And understandably, it makes sense. Because in the real world, your requirements change and the project will always demand for more. Especially once people have seen the benefits of the original solution you’ve built.
But is there a better way? Are we fated to just deal with unwieldy scripts for complex projects ? Will we ever tame the beast that is a large script ?
Yes. And the answer is simpler than you might think. It’s to split your gigantic script into a system of smaller ones that talk to each other.
Splitting your solutions
Splitting a gigantic script into smaller parts isn’t new.
In fact, it’s something that software development has been doing for a long time now. They’ve long recognized that one massively long and intertwined script is not scalable or maintainable.
There are even concepts and books written about modularizing logic in a huge system so that the entire workflow remains scalable and maintainable. Concepts like S.O.L.I.D or books like Clean Code are all major software development practices that explain this. And by doing so, we get a workflow that is flexible, scalable, and easier to maintain than it’s giant counter part.
Okay, I am not saying you have to go read these books or understand the concepts (though, it doesn’t hurt). I’m saying that we can learn from them because the benefits are undeniable, especially if you have to deliver complex solutions with many moving pieces.
By splitting up a huge script into “modules”, you effectively have a consistent barrier from other modules that let’s you “plug & play” different modules or versions as long as the inputs and outputs are consistent.
Now we can think about splitting apart that giant script I had above into 4 modules:
Rationalize geometry
Adding metadata
Push to analysis model
Push to documentation model (Revit)
Which means, I could setup the script to work like this :
Letting me swap out different versions of logic and modules depending on the new requirements and changes that come in. I can also do so without worry about affect the rest of the workflow as much.
And actually, if you keep your scripts fairly clean. You would notice this separation.
Okay, maybe you’re sold on this idea of separating your giant script into smaller ones.
But how do we actually do this ?
There’s data everywhere and everything seems to depend on everything else. And don’t even get me started on the data-trees.
This is exactly what makes it so enticing to just stick with one script. With native Grasshopper, there is no easy way to split one script into smaller scripts without breaking everything.
The Elefront Plugin
Well, that’s where Elefront comes in.
It’s a free plugin that let’s you read/write data to/from Rhino in a consistent manner.
Right, but what does that have to do with splitting our scripts?
It turns out, having a consistent way to read/write data out means we have a way to store our data between scripts. Reading and writing to Rhino sounds like a small thing but it’s really what let’s us create this modular workflow with smaller scripts.
And that starts by changing how we write the smaller scripts. With Elefront, we can create a consistent way of reading, processing and writing data.
We can then leverage this consistency to create more scripts that contribute to overall system. Now, we have a modular approach to solving something complex because it let’s us swap out different scripts when things change or if you have different versions of the modules.
Using Elefront let’s you treat Rhino files as the input/outputs of every script which allows you to split your scripts up, creating this modular system.
Using Elefront
Okay, so how do you actually start using this plugin?
Well, it’s actually quite simple, you have two parts. Reading from Rhino and writing from Rhino.
Reading from Rhino
Elefront offers a few ways to read (the official term is reference) data from Rhino. You can use layers, names, colours, types or even attributes to do this. But the one I use the most is referencing by layers where you can just pass in a layer name and it will return the geometry and it’s metadata to you.
This actually works with Rhino’s worksessions too. Which opens up even more possibilities but makes this concept even more overwhelming than it might already be, so I won’t expand on that.
Note: Rhino worksessions lets you open multiple Rhino files at once, which in this workflow, means you can reference from multiple Rhino files from a single Grasshopper script.
Then, once you’ve read geometry from Rhino, you can also access it’s metadata using Elefront’s attributes. (you’ll see how to attach this metadata later)
Writing to Rhino
When it comes to writing (or baking) data back to Rhino, there’s only one way to do this. First, define the right attributes for your geometry and then use the bake objects component to bake your geometry to Rhino.
Elefront attributes let you define the layer, the colour, the material, etc that your geometry should have in Rhino. They are also what let’s you attach any metadata.
This may seem like a small thing, but it gives you a consistent way to write data out which in turn gives you a consistent way to read data from Rhino.
You can even do more advance data-tree manipulation and put more metadata into Rhino.
You can also view your metadata in Rhino by selecting on your baked object -> properties -> user attributes.
Okay, and that’s it!
You now know how to setup a consistent way of reading and writing to and from Rhino files using the plugin. And yes, I know it seems too simple. Like it’s too good to be true. But really it is that simple.
Grasshopper and Rhino has done a lot of the heavy lifting for us. Elefront, eventhough simple just let’s us connect these functions better.
Final Thoughts
The true value of Elefront, is that it creates a language that your scripts can use to talk to each other. The consistent way of reading and writing to Rhino means a consistent way that smaller scripts can interact with each other.
Without Elefront, the only way to do this is to manually reference and bake geometry. Even then, you can’t bake any metadata to the files. So you’re still heavily incentivised to keep everything in one massive script.
But by splitting your work into smaller, focused pieces, you can make changes to different modules without worrying about breaking the other parts.
When a client changes the geometry for the umpteenth time and you’re not hunting through 500 components fixing it.
Funnily enough, the more you do this, the more upfront work you actually have to do. Because you have to plan and design how your data flows between scripts. You have to resist the temptation to “just add one more thing” to an existing script.
But the payoff is a system that is robust to changes.
Elefront might seem like a small plugin that just reads and writes to Rhino. But once you understand what it gives you, it changes how you approach complex problems in Grasshopper entirely.
Thank you for reading. Consider subscribing if you haven’t, it really helps me know my writing here is useful.