Hey, I have a python class object I am defining within a python sop. I'd like to pass this object further down my sop stream and access it later in another python sop. Is it possible to pack python objects into the stream? I was looking into user data, but that seems more for specific attributes and not data sets.

Much thanks!

Hello!

I don't believe that it is possible to pass a class instance in the way you're describing. There's always a chance that it's not the best way to approach a particular task (although I also try to bundle things in to objects where ever I can), in particular, having a class definition buried in a SOP is possibly not the best way to go as it would make altering the class a real pain if you have many networks requiring it. I'd always favour keeping your classes defined in your python $PATH somewhere and only initialize them when required.

Your python SOP would also be recreating the class definition every time it cooks, which might undo some of the purpose of going for an OO approach to things. I'd also like there to be some kind of persistence in object within a given context, but this may well be flying to far in the face of how Houdini functions as a whole, where passing of data/properties from point to point is more the name of the game.

So it may be best to work the pertinent properties of your class into __init__ (or some such) so you can pass these properties on as an attribute and reconstruct the object later on when you need to act on those properties. This has been my approach so far anyhoo

I guess you could pickle the object into a detail attribute and then decode it in another python SOP downstream. Or store the object in an external module being called by both nodes.

But if I saw that in a tool in a production studio it would definitely raise some red flags. Surely there is another method to achieve what you want that is more idiomatic to the way Houdini is designed?

Having said that I grant there are exceptions… for example, a module that loads a database of some kind that is used in a global manner.

-Jon

Yeah, I looked into the idea of pickling in order to save out python objects with a scene… but then thats when it hit me that houdini already has a method for storing persistent objects with properties… Nodes!

(that and pickling is no straightforward feat if your class makes any reference to a hou object… as SWIG does not play with pickle)

So in the end I figured the best way about things was to create classes in external modules and for any variables that might get referred to by ‘self.prop_thing’ the value of ‘prop_thing’ can get written to a key-value dictionary parameter on a node (IF you want to keep it as separated out as all that) and then all that's required to operate on the data is to initialize a class with that key-value parm and off you go. If you want to encapsulate things further then saving an hda with the class methods in an hdaModule() and your instance variables and static data members get stored in parms.

Basically the thinking came back to a node *type* as a class and a *node* as a class instance (which I believe again is close to how houdini ‘thinks’). Be interested to know others thoughts on this… and if I've got anything horribly back to front!

Cheers,
Henry