Aha, the key/value parameters sound great. Much less hacky solution than reloading env variables (which is a slightly flawed idea)!
In your example, I don't understand what "context.name1" and "context.value1" refer to. Would these be specified in a multiline-string input, or are they knob name/values, or...?
I'm not sure how you could create a reasonably elegant UI using Nuke's current knob types.. Simply adding/removing knobs dynamically would make it difficult to, say, allow nuke.knobDefault("OCIODisplay.context.value2", "[getenv SHOT]"), but I wonder - is it possible/practical to determine what context variables have been used in a config, and dynamically create a knob for each - e.g a knob named "mynode.context_SHOT" - probably not..
Oh, one minor/unrelated question - if a context variable fails to match, conceptually, should there be a way to specify a default value? For example, say I use "${SHOT}.csp" for the main viewer LUT. When someone someone is working on a shot without a LUT, the colourspace will error with "cannot find file newshot.csp" (i.e the SHOT context variable is set correctly, but points OCIO to a non-existant file)
Anyway, must go and sleep. I preemptively apologise if this email is full of errors/typos!
On 02/03/2011, at 4:23 AM, Jeremy Selan wrote: Hi Ben,
Thanks for the note. I was actually just looking at addressing this issue on our end! (if you had waited a week you may have never noticed).
The issue is actually two-fold.
First, I really dont want to consider the envvars themselves to be mutable. (The envvars are just the context defaults.) So what we're going to do is on all the nuke nodes add a "context" group, where you have key value string pairs open by default. So in your case, you could for example set
context.name1 = "SHOT" context.value1 = "ab-123" and these will take priority over the default values, allowing you to change SHOT (or any other envvar) as needed dynamically.
The second issue is actually this one:
The nuke node's cacheIDs only are built based on the knob values, not the underlying OCIO cache ID. What this means is that if you load a common image (marci), render with a default display node, quit nuke, change the OCIO to a similar config but with a different film lut, relaunch nuke, and view marci... You'll get the old image if it's still in the disk cache. (Note you can avoid this with the clear disk cache menu option). But the better solution is to feed nuke the real cacheid, then everything will work automatically.
-- Jeremy
On Tue, Mar 1, 2011 at 3:25 AM, dbr/Ben <b...@...> wrote:
Today I've configured OCIO for a small project at RSP. It was perfectly straight forward, but I encountered a problem..
In short, with the Nuke OCIODisplay node, the env-variables are never reloaded (e.g if changed via os.environ['SHOT'] = 'ab-123')
For example, I have a colourspace that uses ${SHOT}, and have configured Nuke to register OCIODisplay nodes for this. If i launch Nuke with:
env SHOT='ab-123' nuke
..it applies ab-123.csp, as expected, and everything is great.
Then, say I open a script from another shot, cd-654. A new Nuke instance opens, an onScriptOpen callback sets $SHOT (by parsing the script's location), and again all is great, it applies cd-654.csp
The problem is when Nuke doesn't launch a new instance, but the shot changes. Most commonly by opening a script in a clean Nuke instance, e.g:
env SHOT='ab-123' nuke
Then "File > Open" a script from cd-654
The callback changes os.environ['SHOT'] correctly, but the LoadEnvironment call is only performed once (presumably when the first OCIO node is created).
Anyway, this might just be an extremely longly worded +1 for the "flush-cache API method" ticket (can't remember the issue number, and Github's HTTP appears to be down..), but...
I wonder if it's reasonable to expect the OCIODisplay node to call this method somehow? Or if it'd be something I'd have to call, e.g:
def reload_context():
if nuke.thisKnob().name() == "file": # Current filename has changed
cfg = PyOpenColorIO.GetCurrentConfig()
cfg.context.reload()
nuke.addOnKnobChange(reload_context, nodeClass = "Root")
..or if there is a better solution to this problem?
- Ben
|
