Ghx files; the technical definition

Replies to This Discussion

Permalink Reply by Luis Fraguada on July 20, 2012 at 2:06am

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.

Permalink Reply by michael sprinzl on July 20, 2012 at 2:41am

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

Permalink Reply by David Rutten on July 20, 2012 at 3:45am

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

Permalink Reply by Danny Boyes on July 20, 2012 at 4:25am

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.

Permalink Reply by John on July 20, 2012 at 4:44am

'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.

Permalink Reply by David Rutten on July 20, 2012 at 5:28am

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

Permalink Reply by John on July 20, 2012 at 4:35am

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.