Grasshopper

algorithmic modeling for Rhino

Hi everyone,

This is my first post here, so I hope someone can answer my very simple question which I myself have been scratching my head over!

I'm currently in the process of writing a study on the application of parametric modellers in architecture and need to know the correct description for a grasshopper definition as a large area of the study is focused on it. I believe 'macro' (like in microsoft office) is the correct term however my research shows a lot of people referring to them as scripts which I question (scripts are written, usually from scratch in pseudo code, so macro on my view seems more of an accurate description based on the 'component' interface/functionality). Can someone well informed please clarify the difference as I'm now quite unsure what is the best description!

Thanks in advance

Views: 2553

Replies to This Discussion

I suggest you open up a ghx file in a text editor capable of handling XML.  David will be able to provide a better description, but essentially the ghx is an xml file with the description of a gh definition as a set of xml entries pointing to a specific component and its position on the canvas and its connection to the other components in the definition.  I don't believe any specific component code is stored in the ghx (apart from maybe the scripts written in scripting components), only the reference to the specific component.

So all in all 'macro' is not a bad place to start in relation to how the ghx eventually results in a series of components rendered onto the canvas which then all compute their specific code...maybe the ghx is a macro for a macro because the components themselves are compilations of other instructions to fulfill a specific function.

Hi John,

A Grasshopper component is from the technical point of view a state machine. It has a logic part (the solving part) and a memory which handels different stages (you need a memory to know which state you are)

A "script" is a non compiled code which will be feed into a Programm at a certain insert point and the will be compiled in runtime.

A Grasshopper description is dataflow model on steroids.

hope this helps

Hi John,

there's a lot of topics in your post and I suspect a misunderstanding or two as well. Let's start with the runtime portion of Grasshopper.

Grasshopper does not execute a script or a macro, at least using the most common textbook definitions of "script" and "macro". I agree with Luis that 'macro' gets pretty close, as long as you drop the word "text" from the definition of a macro. There is no single piece of textual source code that gets generated from a collection of components, then compiled and then executed. Rather, each component 'knows' how to:

  1. Ask for data it needs to perform a specific operation
  2. Perform that operation
  3. Output the results of that operation
  4. Draw itself onto the Grasshopper canvas
  5. (De)Serialize itself to a gh/ghx database
  6. Some other non-relevant stuff

So at runtime a Grasshopper document is a collection of pre-compiled objects that all speak the same language and can therefore pass data between them. You could consider each individual component to be a small program in its own right.

Grasshopper document files (i.e. *.gh and *.ghx) are not descriptions of this runtime state at all. A GH file does not contain the instructions that a component executes in the performance of its duty, it only contains the name of that component and what components it is hooked up to.

GH and GHX files are written and read not by Grasshopper, but by GH_IO.dll, which is a standalone dll that does not depend on Rhino or Grasshopper. The sole purpose of this dll is to provide an easy-to-use and reliable mechanism to create, serialize, deserialize and search a type-safe hierarchical database with arbitrary elements and nodes. There is nothing 'Grasshopper' about GH_IO.dll, you could use it to store pretty much any data you want.

Since each component is responsible for writing itself to a GH_IO archive, there is no definition of what a Grasshopper file looks like. There is of course a top-level framework layout, but even that is subject to change on a regular basis.

There is an application that ships with Grasshopper called GH_IO_Viewer.exe. You can use this to parse GH and GHX files and browse the database via a tree-view control. But you can also -as Luis pointed out- open a ghx file in any application that can handle Xml files (Notepad and IE are two that pretty much everyone has).

In order to successfully read a GH file and return to a fully functioning document, all the components that are described in the file have to be loaded. Because only those components know what the goop in the GH file means.

--

David Rutten

david@mcneel.com

Poprad, Slovakia

I believe the term Definition is most commonly used around these parts - based on a quick search - to label a gh program.

In its literal sense, a definition describes the meaning of a concept or term. I suppose you could apply this loosely to what a GH file does. (if you were prepared to squint a little and possibly cock you head to one side).

Think of your finished geometry as the "concept" and working backwards through the components you are stripping everything down that goes into the construction of that "concept" until you arrive at the bare bones -- the variables or the "defining" articles.

Personally I don't like the use of script or macro because of the connotations you get from their use in Rhino already.

I have seen, once, the term Schema to describe them but this was short lived and got dropped by the author of those papers, although I think he had a very good point for using it.

'Definition' is also very good, I did consider it myself, however it is quite general and for laymens terms, I felt 'macro' would more effectively describe a ghx to more people - especially the uninitiated - then using a more ambiguous term.

I think that arose because the grasshopper document class was originally called EH_Definition in the source code (EH for Explicit History). These days it's called GH_Document but definition seems to have stuck in the vernacular. I'm ok with it though.

--

David Rutten

david@mcneel.com

Poprad, Slovakia

Thanks for the explanation. I know script isn't the correct definition of a ghx, so in an attempt to assimilate what you've explained, if one is ignorant to the technicalities of the GH source code and how it operates (to simplify for the puposes of discursive writing), a macro does seem to be the best way to describe a GH file.

My understanding of a macro from a traditional standpoint is a set of rules that map a sequence of instructions. I would say this does describe (albeit in a loose way) the way GH functions.

So by seperating the traditional understanding of a macro as simple instructions that then perform an action (why I cited MS Office as an example), then a GH component, like say recording an action and result of pressing a menu icon in Office, could be analogous to one another and avoids over complicating the description for anyone who is less technically minded.

RSS

About

Translate

Search

Photos

  • Add Photos
  • View All

Videos

  • Add Videos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service