> > The main downside I'm curious about with searching for specific channels > as you're doing is having to maintain a list of 'baddies' to search for. >
To me, that's a key part of it. There's so many possible permutations that it's almost impossible to keep track of all of them unless you use a procedural approach, like the one you described. The other procedural approach I have seen used with some success is to look for any add_layer lines that contain one of the default layersets (rgb, rgba, alpha, depth, etc), and remove those altogether, since they will exist no matter what, and the problem originates when somethin non-standard is added to one of those layersets). I think the best strategy right now is a combo of: 1 - Parsing the scripts onScriptLoad to diagnose them 2 - Making sure all gizmos are clean 3 - Intercepting copy-pasted data through a dropData callback. But I still think that the real fix for all of this should come from completely disallowing the addition of new channels to the default layers. For starters, if you try to do it through the interface, it doesn't let you. The only way these channels could have been created in the first place is either through tcl or Python commands, which don't enforce the same sort of restriction. I believe one of the reasons to not disallow such channels right now is so it won't break old scripts that have them. But at this point, and seeing how much effort everyone seems to be putting into this, it sounds to me like most people would be happy to trade that off. That's just my opinion, of course. But the truth is, with this issue having travelled the whole world, I see people that are being discouraged from creating new channel names for fear of creating havoc. And that's a real shame, since there's nothing wrong with creating new channels. <rant mode off> Thanks for sharing that approach to compare used channels vs channels in the script, Erik! :) Cheers, Ivan On Wed, Apr 18, 2012 at 3:03 PM, Erik Winquist <[email protected]> wrote: > > Yeah, sorry.. i wasn't very clear. > > We're still cleaning the text of the .nk script via regex, but like you > describe, that's happening from a python function in nuke once the script > is open. An addOnScriptLoad() callback checks the script's channels as I'd > described previously and if any suspect channels are discovered, at that > point the user is alerted and given the choice whether they want to clean > the script or not. If they choose to, a backup copy of the script is made > and then the .nk text is cleaned and nuke immediately exits. > > I'm interested in how you're launching a new nuke instance from another > process. Re-opening the cleaned script automatically would definitely be > preferable to just having nuke quit like we're doing now. > > > The main downside I'm curious about with searching for specific channels > as you're doing is having to maintain a list of 'baddies' to search for. > > > erik > > > John RA Benson wrote: > > The big headache is, however, that pesky "add_layers" with bad channels > will still be stuck in the script. At least with 6.2, the only way to > remove the layer was with a text editor, which is why I favored the regex > approach outside of nuke. In practice, we run a version of this from nuke > to clean up a lot of issues. Hitting the button does a few things with nuke > to fix internal stuff, but then saves the script and runs this solely as a > text operation on the file. The open (and infected) script is then closed > and the cleaned up script is relaunched (but as a separate process - just > using nuke.scriptOpen(...) ends up just re-introducing the bad layers into > the already open session. Despite 'closing' it, the bad layers and channels > are still in memory). > > > http://www.nukepedia.com/python/regular-expressions-re-module-to-fix-broken-scripts/#findChannelscovers > using the blacklisted layers and finding the channels inside them. > Since we use '-?' (find a match 0 or 1 times) as a prefix to the regex > expression for the channel we're looking for (based on the bad layer's > channels), we find both 'rgb.red' and '-rgb.red'. > > A whitelist of channels to keep is a good idea, but so far hasn't been > necessary. I guess in our case, when a bad channel has been introduced, it > hasn't been carrying a good channel with it in the add_layers function. > > Cheers > JRAB > > > Erik Winquist wrote: > > > We've been wrestling with this like many others. > > Instead of searching for specific layers/channels in specific > configurations, I've instead opted to compare what channels Nuke says a > script contains: > > nuke.channels() > > vs. what channels all of the script's nodes report they're using: > > allnodes = nuke.allNodes(recurseGroups=True) > allchans = [] > for n in nuke.allNodes(): > for c in n.channels(): > allchans.append(c) > > scriptchans = set(nuke.channels()) > usedchans = set(allchans) > notused = scriptchans - usedchans > > In the above example, 'notused' is a python set of any channels that > aren't actually used by the script. > > This, combined with a whitelist of channels that should always be ignored > because they're OK (like depth.Z) and a blacklist of channels that should > always be removed, because they cause damage (like "rgb.red") pretty much > catches anything that could come up now, or in the future. > > The one place I've noticed that this doesn't work is when a node has one > of said channels specified in the alpha slot but the alpha slot isn't > turned on for that node. This instance shows up in the .nk script as > "-rgb.red". If you remove the "add_layer .." from the .nk script and don't > remove all references to that channel, Nuke will not load anything beyond > that line in the .nk script and you'll have an incomplete script in the DAG. > > erik > > > > John RA Benson wrote: > > This thread finally prompted me to do some sharing - > > I've fixed a lot of bad layers in scripts with some simple python (well, > with regular expressions, which are simple but can be confusing). Some of > these scripts were recovered from dead because of broken clones or empty > {}. The usual... > > > http://www.nukepedia.com/python/regular-expressions-re-module-to-fix-broken-scripts/ > > The tips not only clean up dummy layers like redguard - whatever you need > to clean up - but also address some of the other issues that bugger > scripts, like bad clones and the weird {} issue. > > Since it's just working on text, the script works on gizmos (often the > source of mystery layers) that might have junk in them as well as nuke > scripts that have been infected. > > Flavor to taste and enjoy - > jrab > > > Frank Rueter wrote: > > Yeah, this is the single most annoying/dangerous bug in Nuke. I've > encountered this numerous times over the years (since D2Software days > actually). It would be really nice to have some sort of collision handling > if anything threatens to interfere with the default channel sets. > > Have you done a text search for the fully qualified channel names > ("redguard.whatever") in all of the files in Nuke's plugin path? > > > On 4/10/12 7:47 AM, thoma wrote: > > thanks frank - i did just that and it has worked so far. The strange thing > is I did find one gizmo that had a redguard layer in there but not with all > of the channels that were showing up in my script - also no hint of why > they would start replacing rgba. Anyway thanks > > Thomas > > > _______________________________________________ > Nuke-users mailing [email protected], > http://forums.thefoundry.co.uk/http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users > > ------------------------------ > > _______________________________________________ > Nuke-users mailing [email protected], > http://forums.thefoundry.co.uk/http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users > > > > > _______________________________________________ > Nuke-users mailing [email protected], > http://forums.thefoundry.co.uk/http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users > > > -- > erik winquist > weta digital > > ------------------------------ > > _______________________________________________ > Nuke-users mailing [email protected], > http://forums.thefoundry.co.uk/http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users > > > > > _______________________________________________ > Nuke-users mailing [email protected], > http://forums.thefoundry.co.uk/http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users > > > -- > erik winquist > weta digital > > > _______________________________________________ > 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
