algorithmic modeling for Rhino
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?
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.
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?
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.....
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.
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?