Reloading Context's env


"dbr/Ben" <b...@...>
 

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.