Indeed it is difficult. Being visual programming, maybe it is best described visually. Maybe carry around a screenshot of Grasshopper3d to pass out to non informed friends (haha kidding) but yea it is tough to describe. Maybe better to look at some explanations of visual programming itself? https://en.m.wikipedia.org/wiki/Visual_programming_language
I don’t think there’s a single answer that will satisfy, even apart from the fact that different people will require different explanations. Grasshopper is a node-diagram editor. Plenty of those on the market already. Grasshopper allows you to design an algorithm without typing any code. In that respect, Grasshopper is programming.
With the heavy focus on geometry and the fact that GH runs inside Rhino, you can also think of it as a modeling platform, in which case I’d say Grasshopper is a computational modeler.
None of these identifiers preclude the others, none of them is entirely correct or entirely explanatory.
I guess there’s an unbreachable chasm between those who know something about programming and those who don’t. To those who don’t, the descriptions given here will just sound like meaningless jargon. Maybe Michael’s idea about a screenshot isn’t such a bad one, or by analogy, a flowchart.
in addition to all the nice explanations, I always explain it as a tool to easily automate CAD. Because that is what we all do in the end. We let an algorithm model or analyse something for various of reasons.
Assuming these people at least know about:
- installing software
- 3d modeling
Rhino is an application that you install on a computer. Rhino is focused on 3d modelling, thus its interface includes 3d viewports where the model is visualized, buttons to give the user access to different commands that might help to shape the 3d model, and other menus to facilitate the organization of the model because it can get complex!
Usually a 3d model in Rhino is built up from a series of operations. If you make a mistake, or want to change some aspect of the model in the process, you need to go back to the step which you want to change, and recreate the model. Rhino has no default way to associate one command with another. This is why the developers of Rhino create other means by which users can automate the creation of 3d models. Grasshopper is one of them.
Grasshopper is a way to automate all of the 3d modelling and organization process in Rhino. Instead of clicking the buttons and menus to run operations on the 3d model in Rhino, you use Grasshopper to link these commands together. Imagine the process of modelling a [insert easy to imagine thing]. First you might start with [some part of the thing], then you might create [some other part of the thing], and so on. With Grasshopper, you can describe this process and link parts of the process together.
wow…that got long-winded quickly!
That’s easy for you to say!
Pardon my ignorance but who (what) was first?
I’m not sure about the exact history, the first node-based editor I myself worked with in 2000~2001 was Maya Hypergraph.
Reading the above - how much of a newbie are we talking about? If it’s someone who doesn’t even know what CAD is, there’s quite a lot of explaining before you get to Grasshopper…
Like explaining a contactless debit card to someone who doesn’t know what a bank is - there has to be some base understanding before the next level can make sense. It’s hard enough to explain to my architect friends why Grasshopper is useful, never mind my granny!
Personally, I always liked the self-explanatory name “Explicit History.” Grasshopper is as if you could go back in your Ctrl-Z, change something, and have the changes propagate. But as an explanation, it requires an understanding of how CAD works.
My grandma made cakes, manually. She recorded her actions and what materials she used. She wrote recipes. The recipe was a program. Then her granddaughters could make exactly the same cakes 70 years later. Just repeat the recipe, the program.
My grandma made crochets, manually. She recorded also her crochet patterns. Those were programs (more complex than C++ in my opinion). Today her granddaughters can repeat her crochet patterns. They run her programs.
My grandma was born in Finland when it belonged to Russia. She was a skilled programmer knowing nothing about “programming”.
Regarding the history of visual diagram programming, I’d say that FBP was an early concept (Flow Based Programming, a more strict definition than GH) which can be attributed to J.Paul Morrison, which “discovered” [sic] in the mid seventies (well, a bit before that, but commercial FBP applications were deplyed in mid-seventies).
At first J.P.M. used pen drawn diagrams, later he designed a graphical diagram tool (DrawFBP, which he’s still maintaining) and he also implemented his (more strict) definition of FBP in some modern languages (C++, Lua etc) at the age of 80+.
Some interesting facts about the history of FBP:
JPM published his first edition of his book on FBP on the site linked above. See also https://groups.google.com/forum/#!forum/flow-based-programming where you can still chat with Mr J.P Morrison.
I really love your example.
Younger people tends to disregards older generations for not understanding modern technologies These people were equally skilled, just the set of skills was different.
Then in your example, the “parametric” part would be the proportions of ingredients, time in the oven, or temperature. In the case of baking, which is extremely sensitive to such considerations, most of what emerged would be horrendous garbage. It still takes a lot of tweaking to come up with a decent cake, not unlike what’s required in Grasshopper.
Yes, overclocking may smoke the cake if you don’t watch out.
I have recorded a video about “what is Grasshopper?” First i explained about macros then explained the scripting thing and finally jumped to record history in rhino and finally explained several visual programming languages
Hope it helps
A very concise explanation for anyone who’s interested and most importantly, doesn’t assume a lot of background, which was my major complaint. Thanks.
Pictorial blocks with input fields, connecting wires that change a drawing immensely efficiently.
I’ve been in the situation before and the best way i’ve managed to explain it;
Unlike traditional modelling, parametric modelling tools such as grasshopper, allow for non destructive modelling.
While it usually takes a longer time to setup up properly compared to traditional modelling, the parametric model can be changed non-destructively, allowing one to explore 1000’s of options by just changing a single number and skipping the whole remodelling phase.
Now i know this doesn’t cover everything and even has some half-truths to it, but by my experience, it is the explanation that bridges the gap the fastest.
I have now watched the video from parametric, as well as the introduction tutorials from David a while ago. I am just starting with Grasshopper, but I am an experienced Rhino user. Well, not experienced in all aspects of it, but enough to pursue and support my hobby, which is designing and building model airplanes. So I am not the “civilian” as per the TS definition, but I still need to learn a lot about GH.
What I believe is a bit under exposed in all of the above explanations, is the fact that GH does not need to be the design tool from scratch, and can very well be employed as an enhancement of “manual” Rhino designs.
As an example, see my first real GH design generating a simulation of a retractable landing gear, described here: Move animated objects
The result is then baked into an already present Rhino model of the airframe.