Feature Request: Disconnect Static

I know people have discussed different ideas about data persistence in Grasshopper, and its possible someone already suggested this. If so, I apologize. I just wanted to write out the idea while I had it, and didn't search the previous ideas very thoroughly.

When disconnecting all the inputs to a parameter component or a panel, it would be extremely useful to have an option to store the values (in their state at that moment) as static input to the notepad or parameter.

Without this feature, if I have a bunch of data in a panel, and I want to make it static, I have to stream the contents, navigate to the file I streamed to, then copy and paste back into Grasshopper.

In addition to being able to "break" panel components out of the dynamic solution stream, doing the same thing with parameter components would allow for definitions to be quickly segmented and split, which is extremely useful for both reducing the solution time of a definition, as well as for throwing up examples onto the forum without having to recreate the whole situation from scratch. It would greatly aid troubleshooting when there are problems with the definition, or bugs in Grasshopper.

Thanks,

Ben

before disconnect statict:

after disconnect static:

Replies to This Discussion

Permalink Reply by David Rutten on June 27, 2011 at 4:19pm

Hi Ben,

the Panel has some clipboard functionality as of recent which should at least make this process a lot less involved (Copy All Content & Copy Data Only items in the Panel menu).

The reason I don't want to add this as a feature just yet is that I cannot write certain types of data to the ghx file. Curves, Meshes, Breps require OpenNurbs (de)serialization which I haven't included yet. So this sort of 'hard-copy' feature would either only work for some data types, or it wouldn't properly serialize for others.

The good news is that Steve is planning to or has already added serialization support for many Rhino geometry classes so after I hook that up in Grasshopper this would be a reliable and consistent feature after all.

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Benjamin Golder on June 27, 2011 at 4:37pm

That makes complete sense. Thanks for explaining. It certainly changes the relationship to 3dm files if Grasshopper can store the major geometry types. Then .ghx would no longer just be an xml file composed mostly of information on components and the solution graph -- it could have large amounts of data stored within. Such portability (and flexibility in the role of Grasshopper in relation to rhino data) would be really really nice. I'm looking forward to it.

Permalink Reply by Benjamin Golder on June 27, 2011 at 4:39pm

I also really like the idea of potentially being able to serialize and deserialize pieces of geometry separately rather than just as 3dm files when using the SDK. That would be a really great level of flexibility for data persistence.

Permalink Reply by Benjamin Golder on July 8, 2011 at 3:12pm

With Python, I figured out how to store geometry and really any other object that is based in the RhinommonSDK (therefore, no data trees!). With cPickle, you can store any little chunks of data or RhinoCommon-based geometry to a file path and retrieve it. If you wanted to edit the code (it is really simple), you could store data trees (or anything else) as python dictionaries. cPickle seems to be really fast.

Attachments: