Can Two GrassHopper definitions communicate?

Since this is something I was planning anyway for GH2, I wrote a very simplistic implementation using standard components for GH1 in Rhino 6.0

(ignore the audio, didn’t realise the screen capture software was also recording Harmontown that was playing on my other screen).

6 Likes

Cool!

But that wouldn’t work in GH 0.9?

// Rolf

I’m not even supposed to be messing with Rhino 6.0 for non-critical stuff, let alone Rhino5.

2 Likes

What would be the benefit of such workflow or reasons to use it?

Does it result in faster execution time or it would be more ‘clearer’ to read the gh definition??

Let me give you and example:

I work a lot with very “dirty” meshes. They need some very heavy processing for cleaning them up before I can start doing my atual analyse of the. If the GH definition is to recalculate starting from this cleaning process, every change (like iterative form finding) would take forever. I can’t even have the Cleaning Definition opened because it slows everything else down. For other steps in the process I have different definitions for different meshes (depending on quality), so therefore it makes sense to modularize the definition for only those steps that need variants. And so on. But at times several such steps must be active at the same time in a long process chain (due to user interaction, one can not save part-results temporarily only to open next definition, and so on, it must be one responsive chain of definitions).

Although there may be alternative solutions, like DataDams, and logical “process paths”, too big definitions isn’t easy to maintain. Definitions should be like components (chained into networks), only on a higher level.

// Rolf

1 Like

In addition to @RIL’s example, here’s what I imagine this is useful for:

  • You can split up large files into consecutive smaller files. Making each file more readable, more re-usable, and more debuggable.
  • You can store various states of data to work on, and switch between them either through the GH UI or using the file viewer in your OS. You might just want different states, or you may want heavily reduced versions of the same states so that you can work on a small part of the logic and only switch to the full-blown-it-takes-20-minutes-to-compute finished model at the very end.
  • It allows you to work together with other team members more easily. Person A is in charge of facade shapes, person B is doing the rationalisation, person C is populating facade elements, person D is all about creating shop drawings, machining instructions and material bills, each working in their own gh files but sharing data.

There are other reasons, but these I think are the most important.

Eventually for a proper implementation I’m imagining that both cluster hooks and these data exchanges are the same sort of object. It has to work both to and from separate *ghdata files, and also directly into other *.gh files, and of course across cluster boundaries.

8 Likes

I’ve been asking something like this before on the old forum. There is some definition which should be defined step by step, and it is perfect to have a way to do this spending time for the calculating only current step.
Thank you, it is good long waited component :slight_smile:
I use Geometry Cache now the most problem with it is that you have to find the one to reload in a quite a big definition and then another one etc. Adding to it boolean parameter entrance would be not bad.

Lately our files in the office have become bigger in size and harder to handle (even for a powerful iMac). Something like this would bring so much benefit to the whole workflow! Can’t wait to see it happen!

Thanks

Hey Lorenzo,

it’s already there in Rhino 6.4.

Cheers
David

I forgot to point out that we work in OSX environment, so no R6 for us yet. But i’m positive that improvements and compatibility will surely come soon.
Thanks for the heads up though, we might try to find a windows pc and give it a go! :wink:

Isn’t this what elefront plug in does? I think it enabled something similar to this functionality.

Edit: Nvm, its not exactly what you are looking for.

Haven’t tested it extensively, but for simultaneously open grasshopper files, it looks like Link might be it?

http://www.hksinc.com/hksline/2015/01/19/linking-grasshopper-files/

David,
I am finding the Data Input/Output quite a useful addition. Thanks for that.

I am wondering if it would be possible to implement it, such as that the file path input and output can be set by using a path string as supposed to manually doing it by right clicking the component itself.

Can yes, but as always the question is what should happen if more than one file path is provided.

This is such a common problem that a consistent answer really is needed eventually. So many properties of things could be exposed as inputs, but would either not work or be undefined or convoluted if two or more inputs are provided. Slider and Graph mapper ranges have the exact same problem.

Well,
we could start by allow only one path for the time being. And if users come up with various needs we could address them in a more systematic way.

In my case, the use of Data Input and Data Output is an attempt to break my large definition into usable chunks, and reuse them in other projects as needed. A sort of “seed” file definition.

One other suggestion is to have the Data Output create automatically the file in the same folder where the gh definition is located and allow the Data Input to have string path input.

2 Likes

The Data input/output components are awesome, though I would agree with @robi the option to have a file path input would be super useful as I have to check the tiny writing on the output component to see what file it’s looking at. For now just having it the same as filters that break if you enter multiple file paths may be the data components can do the same.

It would also be great to have the option set file paths locally so if the file is opened on another machine it still works like textures and xrefs etc.

Also, @DavidRutten is it possible to use the Record data component to store the data in the file even after it been closed as currently when you close and open a file it clears all the recorders except the one in use. Even changing the record limit does not affect the loss of data.

It sounds like you might be better off simply writing/reading the data to/from a file. You can serialise arbitrary data to a file through one of the scripting components (I like to use the standard Python pickle module for this in GHPython), or using a plugin such as TreeSloth which had the Pack Data and Unpack Data component developed for this purpose.

Yes, that’s what the new Data input/output components David has written. The issue comes when you open the file the records except the the option selected are empty so it saves empty data over the old data saved in the output. I don’t think a data dam would work either as this clears after the file is closed also. I will have a look at the Python and the Tree Sloth options too.

Ah I didn’t realise those actually write to file, thought the data was just in memory (like the GHPython sticky solution above and the Data Recorder). That’s good to know.

Is it possible to set the destination through python component ?
i’m trying to do it, but i don’t know how to reference right click input in python to set the destination source?

import ghpythonlib.components as gh
gh.DataOutput(x)

it give me a warning:
“Data Output: solver component. warning: No destination file has been specified.”

1 Like