Yeah, I would just use a hidden Text_Knob for storing serialized data. Hiding
it isn’t really required if you don’t care much about people seeing the data,
since Text knobs can’t be modified without a trip through the "Manager User
Knobs" interface.
Your data doesn’t *have* to be pickled by any means; it’s certainly not a disk
space concern, as you alluded to. However, if you do, all you’re doing is
adding another knob to the script the data already pertains to, rather than
having to update, synchronize and error-check a separate file. It’s a nice bit
of compartmentalization, and since pickling allows you to store any Python
object, it can be very flexible.
Now, if you have any kind of a production database, you should *never* need to
store auxiliary information in, on, or around your actual Nuke scripts, but
since one often isn’t available due to studio size, resources, etc., packing
extra information into your scripts can be very useful.
As far as how you structure your serialized data, one knob per object (in your
case, your dict) is a nice straightforward way to organize things.
Hope this helps.
-Nathan
From: Marc Gutowski
Sent: Wednesday, October 24, 2012 6:14 AM
To: nuke-python@support.thefoundry.co.uk
Subject: [Nuke-python] Re: Problem Calling Python script inside of .nk-File/ TCL
NathanR wrote:
A sidecar file is definitely another option, though you do still run the
risk of things falling out of sync. If you are going to use one, though, I
would recommend using something like ConfigParser/iniparse as the interface, as
opposed to rolling your own input/output and formatting handlers.
Alternatively, you could just store your render options as a serialized
dict (via pickle, JSON, etc.) on the root node in the script itself.
hey nathan, you really inspired me in storing information pickled on the root.
i got some questions left,
how to apply this ?
e.g. i have a (prickled) dict, ...add this as custom (hidden) knob on the root ?
why it has to be pickled ?
- i mean disk space can't be an argument when storing e.g. 20 values ?
- is it to store it as one 'container' ?
--------------------------------------------------------------------------------
_______________________________________________
Nuke-python mailing list
Nuke-python@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
_______________________________________________
Nuke-python mailing list
Nuke-python@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
