1. Ocio-Dev
  2. Messages

Re: Reloading Context's env

Jeremy Selan <jeremy...@...>
 

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
Join ocio-dev@lists.aswf.io to automatically receive all group messages.