Is there any plan to eliminate the separation of a gh file from it’s .3dm? I work in a large organization and it is awkward to keep track of an evolving .3dm nevermind when a wholly separate file must also travel down the pipeline in tandem. Is there anyway to connect the two? Or at least have the .3dm throw a flag upon opening saying, “hey, there should be a .gh file attached!”
I haven’t poured much thought into this. GH2 will work in the same way as GH1 did with separate files, but I think it should be possible to package a gh file stream inside a 3dm file.
This would be a logical step given that GH is now part of vanilla Rhino.
Much like textures for materials can be embedded.
Plugging this other topic about storing script data inside a .3dm as well:
Notifying @stevebaer because it seems the type of functionality is similar and might do well with a similar GUI at least.
I really thought one day GH is a fully integrated part of Rhino and you could see every RhinoCommon command as GH definition and add your own definitions and there is a browser integrated so that you can download and add definitions from Food4Rhino. I mean, like you select your stuff in Rhino and then it is send to your GH definition that finally returns a result to Rhino. And stuff. Man, I was dreaming.
Thanks David and Willem. Your previous thread was very interesting, especially near the end re: blocks.
David, I think this would be a VERY useful tool to many people. Considering the increased conceptual integration of GH into Rhino, it almost seems odd that this hasn’t already happened. It is encouraging to think it wouldn’t be impossible and I, for one, would happily be a guinea pig.
The Rhino SDK, where dreams meet reality!
This could be done today somehow. A gh definition can be saved into the 3dm as user data…I guess I’ve could take the xml representation of the gh definition and cram it in there. Then when the file is open, you run a command to extract the definition.
Easier said than done, but it is possible.
If at all possible I’d recommend using the GH byte array data, rather than the GHX xml string.
I wish I knew enough about coding that I could be a collaborator, but I’m afraid all I can do is offer encouragement, beg, and maybe buy beers if you’re in the Boston area.
VCS and DIFF, please, don’t forget VCS and DIFF.
Make proprietary & binary storage formats optional with this in mind. Binary/Scrambled/Protected should always be optional, not the only option, as to make both data and definitions accessible from other tool chains so that any software developers can utilize the GH platform i a zillion ways never thought of yet.
Multiple computations within research projects, for example, needs to be able to verify that identical setups of the processing units (GH components) was used (even stored together with the raw data & results).
In short, GH definitions needs to be exposed, by default. Please.
One further thought, brought up by a coworker:
Is there any way to know which Rhino file goes with any given .gh file (or vice versa)? I know it is best to keep it in the same folder, but occasionally things move, or multiple .3dm’s (with similar names) exist in the same folder.
Just reviving this conversation to see if anyone is able/interested in pursuing this with me. My dream scenario would be:
1 - open .3dm file
2 - Rhino recognizes a .gh file is “attached” (imbedded? i dunno)
3 - Rhino starts Grasshopper and opens definition.
4 - Rhino’s metadata includes some sort of link so our PLM software can also see the connection.
1 - open .3dm file
2 - Document Properties tab includes a ‘file explorer’ kinda thing that displays the associated .gh filename.
3 - Manually click on filename to open GH and associated definition.
4 - Inside GH there is some indication of the associated .3dm (in case it is opened manually, by itself).
Any hope here?
Have a look at
Grasshopper.Instances. Maybe it will help you on your way.
Thanks David. I’ll see what my non-programmer brain can glean.