When is the perfect time to learn Scripting within Grasshopper?

Calling all the OG Developers of Scripting in Grasshopper for their 2 cents. When did you feel the need to learn Scripting (for any purpose) in Grasshopper?

I am actually being FOMOed into all the crazy stuff that has been going around in this space. I can call myself a fair Grasshopper User (been using it for mild stuff for the past 3 years now) and just felt like dipping my toes into coding as well. Although I know that it isn’t a one-size-fits-all kind of solution, do you guys think that there is some kind of a recipe like the kind of expertise/ exposure you need before jumping into direct coding?

I don’t have any direct use case for this way of work as of now. But would like to be ready when and if there is ever a need.

Appreciate your views!!! Thanks :v:

2 Likes

As always - it depends. Grasshopper is a toolbox. Do you need to make new tools or are you happy with what’s given to you.

You can never go wrong when learning new things. Coding skills imho - would be still comparable to general literacy.

Just take the step.

I have started out with edX courses and Sololearn app but it is a matter of personal preferences.

The net is wide and infinite.

2 Likes

I’m curious about this too. If you could start again and choose, would you prefer Grasshopper be taught alongside Rhino from the beginning-ish, after some moderate familiarity with the toolset, or sometime as a later “add-on”? Feel free to expand on this as I suspect the answers are going to be more nuanced than what might neatly fit into these 3 categories.

In detail Scripting is a bit different from programming.
If you’re going to use grasshopper then you are more a designer in term of architect or product designer or visualizer or everything related to design but if you are going to scripting it means you wasn’t able to solve your problem with current toolbox or addon which provided for designer with GUI, if you upto programming , use VSCode in parallel,programming is harder than it sounds, you should be pure problem-solver but at the same time you gain more enjoy in cost of time.

IMO, the answer is more about you than it is about Rhino or Grasshopper in particular.

There are people who genuinely enjoy building tools, people who can do it if they have a good reason, and people who simply prefer to use tools someone else has built and (hopefully) tested.

Figure out which group you’re in.

The first group: As soon as you understand the basic types of objects Rhino supports, take a look and start to understand how components work and what’s going on inside each of the little boxes and in the wires. Even if you don’t spend a lot of time on it right then, this is the kind of information that you’ll benefit from turning over in the back of your mind until you need it.

If you’re in the second group, try to find or wait until you have a good personal use case and implement it. I think a reasonable example would be one of the ‘this nest of GH components is getting complicated; how do I box them up into sets?’ type discussions we see here.
(also see: Hops)

If you’re in the third group, be cautious: most people aren’t very effective learners if they’re not interested (or even don’t like) the subject matter. Pick a time when you’ll be mentally receptive.

3 Likes

Coding should be taught first. Architecture is a bastard child of a mathematic system and fine arts. Nearly all the buildings are based on a modul system which could be described as a set of variables.

My answer is: coding, grasshopper + rhino and finally advanced Rhino functios. The vitruvian triad is: firmitas, utilitas, venustas. The strength and utility come first.

2 Likes

Well, that certainly sounds like a coder’s point of view… If your goal is to learn coding, then perhaps the first statement is true. Reducing architecture to just solving some kind of equation with multiple variables is however a very limited view and quite open to discussion. And i would say that most people don’t come to Rhino to learn coding. They come to design and build stuff.

My personal opinion is this: Rhino, scripting, Grasshopper, scripting in Grasshopper (in that order). Why?

I often see requests from people wanting to learn Grasshopper but not necessarily Rhino. I have never understood this, because Grasshopper is simply programming Rhino’s native geometry engine, and if you don’t understand how that works, you will always just be connecting a series of black boxes without understanding what they are really doing inside. You want the instant magic show and don’t really care about what the illusionist is doing behind the scenes.

So understanding how Rhino and a minimum of how its NURBS engine works is for me essential. Afterwards can come the automation.

Why scripting directly in Rhino before Grasshopper?
Because it will teach you more about how to program. Grasshopper’s script components already have a bunch of semi-intelligent automation built-in - stuff that is invisible and again works magically - but since you don’t see it, you never learn how to do it yourself. (I am also always surprised that a lot of people don’t even realize you can run scripts directly in Rhino, they think the only way is via Grasshopper)

Learning scripting directly in Rhino first gives you the understanding of the basics of programming - variables, loops, conditionals, etc. as well as a lot of the geometric function calls that Grasshopper components call behind the scenes. The built-in automation of the GH components isn’t there and won’t get in the way of your learning experience. You interact directly with the Rhino document or application.

After that follows Grasshopper first using native components - it’s a visual extension of scripting, you will already understand what the components are doing, and there you can begin to enjoy the in-built intelligence provided by the components.

Lastly, scripting in Grasshopper to extend the range of your power by being able to create your own custom functions.

That is, of course my personal opinion… YMMV. :stuck_out_tongue_winking_eye:

7 Likes

I have been practicing architecture for a long time now and I wish that I have taken the coding approach much earlier.

Take Aalto for example - he based his designs on the environment they were build in. Whole critical regionalism movement started with understanding the boundaries. The construction and dimensions follow physical laws - whether you like it or not. There is a pattern behind everything.

Designing and building stuff without consideration is just a mess. Picasso mastered the rules before he deconstructed multiple perspectives into one painitng. Cinquecento painters revolutionised the (Western) way of design by introducing strict rules of perspective.

Systematic and structural thinking does not exclude freedom to create form. Quite frankly the other is true. It refines the shape and gives the purpose.

Corbusiers experiments with high rises have birthed monstrosities that destroy human lives all over the world. The illusion of a deisgner as an omni potent creator takes a toll on the design users - whether you like it or not.

1 Like

Ah, another philosopher… :roll_eyes:

Consideration \not= Coding

and maybe

Coding \not= Consideration (necessarily)

In general, the best time to start to learn scripting is 5 years ago. The second best time to start to learn scripting is today.

3 Likes

coding = building stuff

Need consideration, good planning and design, too.

3 years of “mild” grasshopper use (to take your phrase) sounds like perfect exposure before coding. It also gives you a potentially perfect starting point - aim to replace bits of your existing GrassHopper scripts with code blocks. That’s a great manageable task whilst learning

5 Likes

I startet early to challenge myself and because I‘m curious. That is my motivation. If you are bored or hit too many limitations, anything which helps you to workaround it, will motivate you. You should never try to master a technology. You don‘t learn Rhino or Grasshopper, you learn Surface Modeling and Programming. So your aim should be to eliminate the technology from your skillset.
And one more advice, keep things as simple as possible, but as complex as required. It is so critical to truly understand. Once your understanding becomes clear, you find solutions to your problems. Be patient, I‘m not as smart as I would like to be. But i see progress :stuck_out_tongue_winking_eye:

5 Likes

Thanks, guys, for all of your responses. It now makes sense to begin this journey!!!

Cheers

When you start keep the initial goals simple. I would focus on automating some task that you already do. I’ve had people ask how to get started with scripting and their initial goal can be such a difficult thing to solve that they set themselves up to fail right away.

If you are doing this in grasshopper, maybe figure out how to implement what an existing component does with a script component. Then figure out how you could combine two existing component functionalities in one script component.

4 Likes

This 100%.

Start small and simple.

Keep it super basic, without digging into the Rhino/Grasshopper API. Have a bunch of math components on your canvas? Combine them with one scripting component. Format several parameter values into a single file name, or export them to CSV. Parse a CSV file to get some data into Gh.

One of my favorite uses for scripting components is that I can hand off a gh definition to a colleague without including 3rd party components. Recently, I needed a component that generates random but contrasting colors in sequence. There is a component for this in Wombat. But that was the only 3rd party component in the definition. So I took a stab at writing it in python and it worked! (Huge thanks to Grasshopper team for making simple type conversions automatic; ‘128, 200, 255’ reads as a color.)

1 Like