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 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
_______________________________________________
Nuke-users mailing list
[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
