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
