Hi Foundry, Since starting this thread back in Nov. I personally haven't ran into any major issues with the add_layer problem mentioned, until recently.
The Foundry says that this is a "third party" issue but under similar conditions (creating new layers that make their way into scripts, gizmos, comps), this could possibly be recreated at any facility. With the attached files, I have been able to reproduce this bug but haven't narrowed it down to the catalyst. It could be the redguard1.glow or the rgba.water channels or a combination of these channels when mixed together (e.g. channels existing in compA and importing/cutting&pasting another comp with similar channels). Just CC'ing the thread contributors so ya'll know what's up. BTW - I recently heard from a buddy at Imageworks that this issue has brought some renders down! Best, Dan On Fri, Nov 25, 2011 at 7:33 AM, Diogo Girondi <[email protected]>wrote: > I have my doubts about messing with this stuff. From what I see is more of > a matter of people paying more attention to what they author/share and > treat as project/pipeline independent than a actual problem. > > Implementing ways to control/restrict this stuff via user interaction > could in fact end up severely crippling certain workflows. Like not > allowing gizmos to create custom channels/layers on a more invisible way to > artists without prompting them for action. > > However I do agree that Nuke should deal with channels/layers conflicts > more elegantly, and could benefit from having a few ways to track down > channel/layer creation/usage. A Layer Info window that lists all the layers > present in a script with their usage and creation points would suffice in > my opinion. > > A window with something like: > > Layer name, channels, used by x number of nodes, created at (node > name/init) > > > > As for allowing the addition of custom channels to the RGBA layer I agree > that this is one layer that shouldn't allow that. Same would be true for > the RGB pseudo-layer. > > Eight channels per layer is another thing that I find very questionable > since its something you can never access at once in Nuke and can make your > life trickier layer wise. > > > > Cheers, > Diogo > > > On 25/11/2011, at 10:27, chris <[email protected]> wrote: > > > hmm, i can see that is kinda hard to solve this issue without crippling > functionality... however, corrupted scripts are no fun either. > > > > it seems to me that it adding unnecessary channels could greatly reduced > by some confirmation/warnings boxes...like: > > > > if you paste some code into a script that will add new channels, pop up > a dialog panel showing which channels will be added, with a "yes" "cancel" > "strip channels" button > > > > and similarly, if you export a gizmo with custom channels, show a dialog > with all the channels listed. > > > > btw, is there a good reason why rbga.customLayers should be even > allowed? (as those seem to often cause troubles) > > > > i don't often work with a lot of channels, so maybe this options are not > really practical for other typical workloads. one could always add an > option in the preference to turn those warnings off i guess. > > > > just some thoughts > > ++ chris > > > > ps: i also like the idea of feature 15561 > > - Don't generate channel adds at save when the channels are not > referenced in the script. > > > > > > > > > > On 11/24/11 at 10:32 PM, [email protected] (Dennis > Steinschulte) wrote: > > > >> I got an answer from the foundry support team. It's not a > >> bug and they can't see a solver for this issue because it > >> seems to be a third party plugin thing. They have read > >> this mailing list about this topic and will think about > >> the creation of channels, though. I don't have the mail at > >> hand now, but I'll post post the whole answer (incl bugID) > >> in about 12 hours. Cheers Dennis > >> > >> > >> On 24.11.2011, at 21:03, "[email protected]" < > [email protected]> wrote: > >> > >>> I'm still not sure that this breaks anything, but it > >> might... My main > >>> thing though is that we should have the ability to > >> remove/rename > >>> channels from the script through python, for example (not > >> just add > >>> them, like it works now). > > > > _______________________________________________ > > Nuke-users mailing list > > [email protected], http://forums.thefoundry.co.uk/ > > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users > _______________________________________________ > Nuke-users mailing list > [email protected], http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >
:::::::::::::::::: TESTING AREA FOR ADD_LAYER BUG ::::::::::::::::::
1.) NUKE -> FILE -> OPEN -> (before_import_v001.nk)
2.) OPEN ANY OF THE RED SHUFFLE NODES
3.) NOTICE THAT THE SHUFFLE NODES (in 2) IS SET TO (rgba)
4.) FILE -> IMPORT SCRIPT... -> (unpremult_node_BAD.nk)
5.) FILE -> SAVE AS... -> (after_import_v001.nk)
6.) FILE -> CLOSE
7.) FILE -> OPEN... -> (after_import_v001.nk)
8.) OPEN ANY OF THE RED SHUFFLE NODES
9.) NOTICE THAT THE SHUFFLE NODES (in 2) IS SET TO (rgb) ALONG WITH OTHER
SHUFFLE NODES IN THE COMP.
===========================================================
THE CULPRIT OF THIS PROBLEM IS THE ADD_LAYERS DEFINED IN THE IMPORTED SCRIPT
(unpremult_node_BAD.nk).
IF THIS NODE WAS CUT AND PASTED OR IMPORTED INTO THIS COMP THE ADD_LAYERS
DEFINITIONS
BECOME PART THE COMP SCRIPT AS WELL AND BREAKS THE COMP UPON SAVING.
NOW TRY COMMENTING OUT THE (add_layer) in the (unpremult_node_BAD.nk) FILE
AND RUN THROUGH THE STEPS AGAIN. YOU'LL NOTICE THAT THE ISSUE NO LONGER EXISTS.
add_layer {rgb rgb.UV}
add_layer {rgba redguard1.glow rgba.water}
===========================================================
before_import_v001.nk
Description: Binary data
unpremult_node_BAD.nk
Description: Binary data
_______________________________________________ Nuke-users mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
