Internalizing and writing/reading custom class parameter

Hi,

I have created a custom class MyItem for a parameter and I would like to be able to internalize and save the instances in a parameter.

The instances of custom class MyItem can have variable information in itself. The information is stored in GH_Structure as normal GH_Goo types.

MyItem is wraped in MyItemGoo class that derives from GH_Goo.

There is also the Param_MyItem class from GH_PersistentParam<MyItemGoo> that allows the custom items to be used as GH parameters.

This all is working fine without internalizing.

What I don't understand now is how to get the internalization to work. Which classes need to implement what methods (Read, Write, Serialization)?

I have tried to set up the Read and Write in the Param_MyItem class. Got so far that after internalization for the first save the data is writen from PersistentData and when reopened its read into VolatileData and is correctly visible in the component (Somehow it does not stick to PersistantData with SetPersistantData). And after second save the data is lost because it is not in PersistantData for the writer to read. I don't quite understand the usage of persistant and volatile data and I am not sure if I am even working in the right direction.

Could someone explain the general best practice to implement this, custom items serialisation, internalization, read, write, duplication. What do I need to do to save the custom data in GH parameters?

Thanks,

Replies to This Discussion

Permalink Reply by Kaiko Kivi on March 13, 2014 at 3:45pm

Seems that I found the answer.
It is the MyItemGoo that has to derive the interface from GH_ISerializable and implement the Read and Write on the data of the single MyItem it containes. The rest is up to Grasshopper to know where, when and how to store and sort the data of any of these items.
Magic.

Permalink Reply by David Rutten on March 14, 2014 at 3:29am

Magic indeed. In GH2 all IGH_Goo (which will be called IGoo then, I'm removing all smurf naming from Grasshopper) must be deserializable, making this stuff more robust and easier to find.

David Rutten

david@mcneel.com

Permalink Reply by Kaiko Kivi on March 14, 2014 at 5:13am

Thanks for the jargon post. Guess I had a "Rubber Ducking" moment here.

But I still didn't find out why it was impossible to SetPersistentParam with the data in the parameter class. Maybe irrelevant now.

Can you guess, if there are any limits to the data that can be internalised like this. I currently tested it with about 1500 items that each serialize two GH_Structures with average 10 paths. The gh file went from 250kb to 3250kb. Besides some data not serializing properly (Trimmed Surfaces. I can bypass this in the definition for now), had no scaling problems so far. Would I have to be careful somehow when scaling this data?

Permalink Reply by Steve Lewis on March 27, 2014 at 1:12pm

What if some of the custom custom classes we have written for GH1.0 inherit the IGH_GOO interface but aren't necessarily fully deserializable? This will be a significant break if I have to re-write all these classes. A lot of these classes obtain properties through volatile data and don't need to be deserialized.....

Permalink Reply by David Rutten on March 27, 2014 at 2:04pm

You will have to rewrite no matter what. GH2 SDK will not be compatible with GH1 SDK. Not even remotely.

However how you implement your specific type of goo is up to you. You're free to lie about whether or not you successfully serialized your goo. If the data is never written to begin with (for example because it only ever is generated as the output of a component) then the problem will never arise.

But note that it is always possible to force goo to get stored in the file by internalising a parameter. How and when you choose to inform a user that this cannot be done with your specific type of goo is up to you.

David Rutten

david@mcneel.com

Permalink Reply by Steve Lewis on April 2, 2014 at 4:33pm

Thanks for reply.

ok, yes i do sometimes internalize those parameters I need by reading and writing the value to the component on save and open. Seems like I may be ok then.

yes we will have to re-write for GH2, i guess the question is how much we have to re-write!!!!

Probably too early, but, do you forsee GH2 be open to 3rd party developers to the same extent as GH1? Off the top of your head, do you have a map of when you might start exposing GH through an SDK?

RSS