Very Large Gasshopper files, Collaboration, UI ideas

by Dieter Toews

Sep 3, 2013

Hi all,

First of all David has already responded to some of the ideas I was planning to raise here.

With 1.0 getting close I thought I'd come back out from lurking on these forums and give a bit of feed back:

Last year a group of graduate students at McGill did this: http://web.farmmresearch.com/pavilion/

I was a member of this group and was one of the people involved in the creation of the grasshopper file (see screen shot at bottom of post - please excuse the spelling errors if you find them). There were effectively no drawings, only the grasshopper script, a bit of post processing in soildworks, cnc fabrication, and hand assembly using labels etched in at the time of cnc fabrication.

As you can see from the screen shot the GH file is a hellish nightmare, right on the edge of the memory limit of rhino 4 (which we had to use because of a minor difference in the way rhino 5-GH handled sweeping), and, towards the end, it took about 15 minutes of computer time just to get to the point were we could work on the script because of all the calculations need in the stack.

Here is a list of things that would have really helped us:

1. More programming experience. i had a bit, most others didn't. David can't help to much with this in a direct way.

2. Clusters: at the time we started clusters didn't work well, by the time they did we were almost done - oh well. I do have some ideas about how it would be nifty for clusters to have version control so that the master assembly could revert thinks that cause other things to break. - I'm sure this can be done manually right now but i have never tried it. could GH be plumbed into something like svn?

3. Concurrent editing - Like a video game. It would, i imagine, require some sort of cloudy file storage and server solution or something but there were MANY hours were 3 or more people were crowded around one computer trying to solve a problem. Alowing everyone to have there own view of the file that stayed in sync would just have been more comfortable...

4. Progress bars and the UI and Display running in a separate thread from the solver. Davids addition of esc to allow us two sometimes save ourselves if we connected a wire wrong but often not. It would be cool to be able to interact with the grasshopper file right away and sill know that the solver was working away (especially when a single run of the file took 15 minutes). Progress bars would be nice on any component taking more than a second or two to run (which was the case with many of our components - especially the ones that we wrote ourselves) but they only make sense to add after the threads for the solver and the UI have been separated.

So, anyone else done a really huge GH file? Thoughts?

Load Previous Replies
  • up

    Nick

    I'm not entirely sure what's going on in your file, as I am at work and can't really dig deep into it, but couldn't it have been separated into smaller parts? aka achieving a certain threshold, baking and then continuing in a new file from this result?

    12

    Sep 4, 2013

    Load Previous Replies
    • up

      Diego G

      Hello:

      This is a topic that I wanted to write since quite a long time ago. I also have done huge files and encountered similar problems to yours. In the file attached there is one of the large files used in my thesis.

      To tackle large definitions and their extremely long and confusing wires I used hidden lines and panel to create variables. So that I can partition large files into sections without having wires everywhere.

      Here Is the way I do it:

      I take the result of a component and connect the correspondent primitive to it, after that I put a panel on top of it with the name of the variable and leave the yellow color.

      then I create a copy of the two originals and connect the first to the seconds and make the wire connecting them hidden. After that I change the color of the second panel to some other (in my case green). So that I know that it is a child object to the first.

      I have attached an example also.

      This allows me to cut definitions in sections and improve their clarity. Having all those little green panel telling you what is what and the type of primitive you use helps in documenting and understanding the definition.

      Also you do not need to bake parts. However auto-bake and auto-read is another trick to speed up your definitions.

      this is the way I tackle large definitions. I know that is cumbersome, and probably everyone has or will develop it´s own notation. but I believe that it necessary to define this sort of variables in large definitions.

      Perhaps David given those examples will find a better solution or develop something in the UI.

      Regards

      Diego

       

      1

      Sep 4, 2013

      • up

        Ramon van der Heijden

        Hi,

        I know this thread is already two months old, but I'm sure many people are struggling with this issue every day. I have developed a GH add-on that tries to address the issue as described above.

        Elefront is an add-on that is some sort of enhanced version of the [geometry cache] component. It allows the user to bake objects to Rhino, while at the same time storing an infinite amount of meta-data INSIDE the rhino object. These objects can then be referenced back into GH in a different session. Referencing can be done simply by a nickname that was provided upon baking, much like [geometry cache], but referencing can also happen based on any of the user attributes (meta-data) that were stored inside these objects.

        This way, a Rhino model can become more of a database rather than just a model. In order to keep your models clean and in order to enable collaboration on your GH projects, the reference components also work on objects that are brought in your Rhino model as a worksession.

        This way you can divide your Grasshopper process into sizable chunks, that output data models that can be queried like a database.

        The workflow would be very similar to what David is describing in the *.ghcache proposal, except for that the *.ghcache file would be an actual model, that can be opened and interpreted by a human. Even without the use of GH. These intermediate models can also be used for several different purposes. For instance, one could "bake" a wireframe of a steel structure, that has all attributes for all steel members embedded in the wires. This wireframe can be used by a structural engineer for calculation purposes, while someone else can interpret the data to define IFC models or Rhino surface models from the very same wireframe.

        The add-on is free and can be downloaded here:

        http://www.food4rhino.com/project/elefront

        Please let me know if you find this interesting.

        Best regards,

        Ramon van der Heijden

        1

        Nov 3, 2013