Nuke node loses connections in certain trees

[dbr]

In the below node graph, connect the "A" input of the ChannelMerge to the TimeOffset. When you copy/paste the node graph, the "A" input becomes disconnected (which also happens when the script is saved/reopened)

It is caused by something to do with the knobChanged callback - if I remove the inputChange part of this method, the problem stops (but some functionality no longer works):

def cryptomatte_knob_changed_event(node = None, knob = None):
    if knob.name() == "inputChange" or knob.name() == "cryptoLayer" or knob.name() == "cryptoLayerLock":

It's strange - only seems to happen with the ChannelMerge, regular Merge and other two-input nodes seem okay.

set cut_paste_input [stack 0]
version 10.0 v4
push $cut_paste_input
TimeOffset {
 time ""
 name TimeOffset7
 label "\[value time_offset]"
 selected true
 xpos 13246
 ypos 6816
}
set Ndd6dafc0 [stack 0]
push $Ndd6dafc0
add_layer {crypto_object crypto_object.red crypto_object.green crypto_object.blue crypto_object.alpha}
add_layer {crypto_object00 crypto_object00.red crypto_object00.green crypto_object00.blue crypto_object00.alpha}
add_layer {crypto_object01 crypto_object01.red crypto_object01.green crypto_object01.blue crypto_object01.alpha}
add_layer {crypto_object02 crypto_object02.red crypto_object02.green crypto_object02.blue crypto_object02.alpha}
Cryptomatte {
 name Cryptomatte6
 selected true
 xpos 13150
 ypos 6876
 matteList ""
 cryptoLayer crypto_object
 expression a
 keyedName "ID value not in manifest."
 previewChannel crypto_object
 in00 crypto_object00
 in01 crypto_object01
 in02 crypto_object02
 in03 none
 in04 none
 in05 none
 in06 none
 in07 none
}
ChannelMerge {
 inputs 2
 operation in
 name ChannelMerge7
 selected true
 xpos 13246
 ypos 6941
}

[acjones]

I'm not entirely sure this is a Cryptomatte-specific bug. I was able to reproduce the same behavior with an empty "pass-through" gizmo that has only a simple knob_changed event. What I noticed is that as soon as I add a call to fetch the node's metadata, the issue occurs. If you create a gizmo called "repro_input_change_bug" and run the following code in the script editor, you should see the same issue when duplicating the setup -- but only if the upstream node graph includes a TimeOffset node (even TimeOffset=0, as in your example).

What I'm thinking is that maybe there's some kind of early-out for metadata evaluation in the TimeOffset node. Otherwise, perhaps there's some nuance to metadata evaluation that would avoid this problem. A workaround might be to use FrameRange and AppendClip to give you a similar behavior as TimeOffset. (I wasn't able to reproduce the issue using other time manipulation nodes.)

I think this would be a good thing to take up with the Foundry, but we can keep this issue open in case we come up with a reasonable workaround, or until the bug is fixed (on our side or theirs).

import nuke

def setup():
    nuke.addKnobChanged(lambda: repro_input_change_bug_knob_changed_event(
        nuke.thisNode(), nuke.thisKnob()), nodeClass='repro_input_change_bug')

def repro_input_change_bug_knob_changed_event(node, knob):
    print node.metadata()

setup()

[mheberlein]

We just had a similar issue with "Dissolve" and "Merge" nodes adding or replacing input connections. Excluding the inputChange events, as described by @dbr, seems to help.

I wasn't able to follow @acjones repro steps but may have done something wrong as I'm not familiar with Nuke callback events:

[jonahfriedman]

I found a hacky solution to this. If node.screenHeight() returns 0 in that function, then we early out as the node is not properly initialized yet.

def cryptomatte_knob_changed_event(node = None, knob = None):
    if node.screenHeight() == 0:
        return # node not properly initialized, do not run setup functions. 
    if knob.name() in ["inputChange", "cryptoLayer", "cryptoLayerLock"]:
    ....

The test suite still passes with that, so maybe it's not the end of the world, but it's obviously a hack and we're still hoping to find a better solution. I have not tested what this does in batch mode.

Here's some things I tried that didn't work:

• Checking node.inputs() to make sure the node is connected
• Calling metadata() on the upstream connected node instead
• Using nukescripts.executeDeferred for the knob changed callback if input changed, to defer the call until later.

[dbr]

The screenHeight check doesn't seem to work with the example in the initial comment with the TimeOffset/ChannelMerge (or, I messed something up while testing)

[jonahfriedman]

That's too bad, that's what I was testing with. Are you on Linux? My tests were all on Windows (though it fixed the problem in Nuke 8 - 10 so I was hopeful it would apply to Linux as well).

[dbr]

I was testing on Nuke 10.5 on Linux, although I shall give it another go today as I may well have done something silly

[jonahfriedman]

I finally got around to testing on Linux myself, and the fix does actually for me. I added a test for it as well in the test suite.

Could you download the latest from the dev branch, and see if it fixes it for you?

[jonahfriedman]

I'm going to go ahead and close this, I'm pretty confident it's actually fixed since I did both reproduce and see the issue fixed on Linux. Please reopen if I'm incorrect.

[acjones]

For posterity (and since at some point it would be nice to remove the workaround code), here is the Foundry bug id: 320561

[andranikvfx]

+1 here, we are having this same issue on Nuke10.5v5 on windows 7.

[jonahfriedman]

What version of Cryptomatte are you using? I ask this because we fixed it.

[andranikvfx]

Some of our machines didnt get the latest version deployed. We are going to be testing 1.2.0. Keep you updated. Thanks Jonah