search

Psyop / Cryptomatte

Cryptomatte Nuke plugin, Fusion plugin, sample images, and specification
BSD 3-Clause "New" or "Revised" License
637 stars 152 forks source link

[Nuke] Allow Gizmo output to go to a channel instead of layer #47

Open dgirondi opened 6 years ago

dgirondi commented 6 years ago

"ShuffleCopy_embedMask" (out knob) could be replaced for a "Copy" (to0 knob) node in order to allow users to output to a specific channel within a layer instead of outputting the same thing to all 4 channels of a layer.

I would also rename the gizmo "Input1" to "Input" to avoid giving the impression there are multiple inputs on the gizmo.

jonahfriedman commented 6 years ago

Hi @dgirondi, thanks for all your feedback.

"ShuffleCopy_embedMask" (out knob) could be replaced for a "Copy" (to0 knob) node in order to allow users to output to a specific channel within a layer instead of outputting the same thing to all 4 channels of a layer.

I had to go double check and it seems you're right, it's not possible unless the specific channel is also its own layer, such as "alpha". Pull requests here are welcome, provided they don't break backward compatibility (see below).

I would also rename the gizmo "Input1" to "Input" to avoid giving the impression there are multiple inputs on the gizmo.

I never actually noticed the little "1" in the node graph UI for the Cryptomatte gizmo before, but you're right, it's there. Same deal here, patches welcome (unless they break compatibility).

Breaking compatibility would mean a nuke script made with the old gizmo should open correctly with the new one. I think the input knobs are special in that regard and it'd probably be ok, but it'd need testing. For the 1.2 update we had fairly large changes but managed to keep this kind of compatibility. (The only exception is that the "preview" channels changed).

dgirondi commented 6 years ago

Renaming the Input shouldnt break anything but replacing the Shuffle there probably will since scripts saved with an older version of the Gizmo would only have the layer name ("layer") stored instead of "layer.channel".

Perhaps

jonahfriedman commented 6 years ago

Ah, right that makes sense about the shuffle replacement. There's another wrinkle there as well, where the channels need to be stored on knobs outside the gizmo that have no other purpose than making sure the channels exist at script load time (otherwise you get errors). That one is probably fine however.

Anyway, whether or not this can be done in a backward compatible way needs to be investigated. If it can't, it'll have to wait until we break compatibility (and no idea when that might be).

dgirondi commented 6 years ago

Humm, I'll take a better look at that gizmo to see if I can come up with something.