Proper use of the VolatileData Property in GHPython Components?

[ed.p.may]

Hi all,

I wonder if someone might be able to provide some advice on a Grasshopper/Python related item?

The scenario is that (as part of a larger plugin) I am building out a GHPython component where I’d like to able to accept many different types of inputs in single node. This includes Panel-Strings/Numbers, Grasshopper-generated-geomerty, and Rhino-generated-geometry. In the case of Rhino-generated-geometry inputs, I’m also trying to pull in the UserText from the Rhino scene (if any).

So - in general, I think I have a solution that works ok so far. The main issue is that in order to allow for so many input types, I need to keep the Component’s input-node type-hint set to ‘No Type Hint’.

This poses some challenges when it comes to getting the Guid and the UserText of Rhino-side objects. In order to try and handle that and get the Guid’s of any inputs, I’m currently walking through the Input Node’s VolatileData and grabbing the ReferenceID for each item input object. So roughly like:

def get_input_guids(_input_index_number):
    guids = []
    for _ in ghenv.Component.Params.Input[_input_index_number].VolatileData[0]:
        try:
            guids.append(_.ReferenceID)
        except AttributeError:
            # If input doesn't have a ReferenceID, its probable a Panel text or number input               
            guids.append( None )
            
    return guids

So I’m wondering:

• is this the ‘right’ way to do something like this?
• Is there any risk / downside to using the VolatileData input in particular? I am not very familiar with this property, and I wonder if perhaps there is some area where it might cause some issues down the line? It doesn’t seem that there is a ton of documentation for this property - to unsure about its use and limitations?
• Are there scenarios in which this property would become unreliable for some reason? In particular, accessing the [0] index item makes me wonder if I’ll be missing something in some other scenario? Not sure I understand that part. Maybe when the user Ctrl-Z 's or something in Rhino for some reason?
• Are there easier ways to allow for inputs of text, GH-Geom, RH-Geom and get the Guid of any Rhino-objects, that are already built in that folks know of that might be a better method?

I’ve attached an example GH file here for reference with a version of my current working implementation. Any advice is always much appreciated.

thanks!
@ed.p.may

input_organizing.gh (12.4 KB)

[piac (Giulio Piacentino)]

@ed.p.may

• is this the ‘right’ way to do something like this?

Well, the answer is, unfortunately not exactly. GH1 did not come with attributes handling from its inception. If adding that in a robust way was a matter of a couple of lines, we would have long done that. David is trying to add some sorts of parallel attributes with geometry for GH2.

@ed.p.may

• Is there any risk / downside to using the VolatileData input in particular?

No, it’s a safe attribute to look up. Please note that most components in between will destroy the history of all the ReferenceIDs.

@ed.p.may

Are there scenarios in which this property would become unreliable for some reason? In particular, accessing the [0] index item makes me wonder if I’ll be missing something in some other scenario?

Sure, you are missing all the IDs of the items after branch[0] (the first one). VolatileData is a IGH_Structure, so it could contain many more than one list. It’s also not guaranteed that item[0] exists, but if you use exactly this setup, it will work.

@ed.p.may

Are there easier ways to allow for inputs of text, GH-Geom, RH-Geom and get the Guid of any Rhino-objects, that are already built in that folks know of that might be a better method?

You’ll have to dig through the GH SDK as you are doing. It’s not complicated as you discovered, it’s just another SDK on top of RhinoCommon. It would be slightly easier in an add-in, but essentially, the same properties would be used. Please note that GH, on a user level, should not really make any difference between where the geometry comes from. Breaking this rule might confuse users.

[ed.p.may]

Hi @piac ,

Thanks so much for your detailed reply. That is very helpful and I will take all that into consideration.

I wonder about your last point there though:

Please note that GH, on a user level, should not really make any difference between where the geometry comes from. Breaking this rule might confuse users.

I think that makes sense - but I’m not sure I understand what you are warning against there? Do you just mean that if the user get a different result if they put in Rhino geometry vs. Grasshopper geometry, this would lead to confusion? That certainly makes sense, except that in my case I think there would be a difference since the RH-Geometry would have attributes, where the GH-Geom would not? I suppose that’s a good point though: providing some warning / notice to the user and/or providing default values for missing attributes seems important.

If I misunderstood your point there though please let me know?

regardless, thanks for the input! I’ll carry on and see how it goes.
best,
@ed.p.may