Suppose I wanted to explain to a “civilian” what Grasshopper is. I could direct them to any number of pages, including the old, moribund forum, but they all assume a prior knowledge of Rhino and are not meant to serve as overviews for the uninitiated. I know what it is - you know what it is, but how would the casually curious discover what it is?
Visually scripting Rhino’s functionalty. Instead of user clicking commands one after the other, a visual network of components (doing essentially the same kind of thing) can run long sequences of Rhino commands, fast, and exactly the same each time you let it run.
Kind of. Depends on who’s asking and what they know about programming. It’s a way of programming Rhino to do what you want it to do, instead of doing it manually. You can also script Rhino/Grasshopper using programming language (code), like VB, C# and Python. But here it may sound even more strange, depening on who’s asking…
You can probably cobble something together from here: https://en.m.wikipedia.org/wiki/Grasshopper_3D
But in short it is a visual programming tool for algorithmic modeling. Commands exist as nodes and you chain nodes together to create a sequence of modeling operations. Atleast that’s what I think it is.
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.