[Nuke-users] cpp file
Hi guys, just downloaded a file from Nukepedia (VectorTransform, cheers Johnathan) which is a .cpp file. Any idea how to install it? Ron Ganbar email: ron...@gmail.com tel: +44 (0)7968 007 309 [UK] +972 (0)54 255 9765 [Israel] url: http://ronganbar.wordpress.com/ ___ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
Re: [Nuke-users] cpp file
On 18/04/12 06:59, Ron Ganbar wrote: Hi guys, just downloaded a file from Nukepedia (VectorTransform, cheers Johnathan) which is a .cpp file. Any idea how to install it? It's a source file for an NDK plugin - you'll need to compile it to a binary file for the platform you're on - or look for it pre-built somewhere... Peter -- Peter Pearson, Software Engineer The Foundry, 6th Floor, The Communications Building, 48 Leicester Square, London, UK, WC2H 7LT Tel: +44 (0)20 7434 0449 Web: www.thefoundry.co.uk The Foundry Visionmongers Ltd. Registered in England and Wales No: 4642027 ___ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
Re: [Nuke-users] cpp file
I see. Never done that before. Anybody compiled this for Mac and Nuke 6.3v7 already? Thanks R On Apr 18, 2012 10:08 AM, Peter Pearson pe...@thefoundry.co.uk wrote: On 18/04/12 06:59, Ron Ganbar wrote: Hi guys, just downloaded a file from Nukepedia (VectorTransform, cheers Johnathan) which is a .cpp file. Any idea how to install it? It's a source file for an NDK plugin - you'll need to compile it to a binary file for the platform you're on - or look for it pre-built somewhere... Peter -- Peter Pearson, Software Engineer The Foundry, 6th Floor, The Communications Building, 48 Leicester Square, London, UK, WC2H 7LT Tel: +44 (0)20 7434 0449 Web: www.thefoundry.co.uk The Foundry Visionmongers Ltd. Registered in England and Wales No: 4642027 __**_ Nuke-users mailing list Nuke-users@support.thefoundry.**co.ukNuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.**uk/ http://forums.thefoundry.co.uk/ http://support.thefoundry.co.**uk/cgi-bin/mailman/listinfo/**nuke-usershttp://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users ___ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
Re: [Nuke-users] cpp file
I can have a look for you Howard From: Ron Ganbar ron...@gmail.com To: Nuke user discussion nuke-users@support.thefoundry.co.uk Sent: Wednesday, 18 April 2012, 10:49 Subject: Re: [Nuke-users] cpp file I see. Never done that before. Anybody compiled this for Mac and Nuke 6.3v7 already? Thanks R On Apr 18, 2012 10:08 AM, Peter Pearson pe...@thefoundry.co.uk wrote: On 18/04/12 06:59, Ron Ganbar wrote: Hi guys, just downloaded a file from Nukepedia (VectorTransform, cheers Johnathan) which is a .cpp file. Any idea how to install it? It's a source file for an NDK plugin - you'll need to compile it to a binary file for the platform you're on - or look for it pre-built somewhere... Peter -- Peter Pearson, Software Engineer The Foundry, 6th Floor, The Communications Building, 48 Leicester Square, London, UK, WC2H 7LT Tel: +44 (0)20 7434 0449 Web: www.thefoundry.co.uk The Foundry Visionmongers Ltd. Registered in England and Wales No: 4642027 ___ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users ___ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users ___ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
Re: [Nuke-users] cpp file
Thanks Howard! Ron Ganbar email: ron...@gmail.com tel: +44 (0)7968 007 309 [UK] +972 (0)54 255 9765 [Israel] url: http://ronganbar.wordpress.com/ On 18 April 2012 13:19, Howard Jones mrhowardjo...@yahoo.com wrote: I can have a look for you Howard -- *From:* Ron Ganbar ron...@gmail.com *To:* Nuke user discussion nuke-users@support.thefoundry.co.uk *Sent:* Wednesday, 18 April 2012, 10:49 *Subject:* Re: [Nuke-users] cpp file I see. Never done that before. Anybody compiled this for Mac and Nuke 6.3v7 already? Thanks R On Apr 18, 2012 10:08 AM, Peter Pearson pe...@thefoundry.co.uk wrote: On 18/04/12 06:59, Ron Ganbar wrote: Hi guys, just downloaded a file from Nukepedia (VectorTransform, cheers Johnathan) which is a .cpp file. Any idea how to install it? It's a source file for an NDK plugin - you'll need to compile it to a binary file for the platform you're on - or look for it pre-built somewhere... Peter -- Peter Pearson, Software Engineer The Foundry, 6th Floor, The Communications Building, 48 Leicester Square, London, UK, WC2H 7LT Tel: +44 (0)20 7434 0449 Web: www.thefoundry.co.uk The Foundry Visionmongers Ltd. Registered in England and Wales No: 4642027 __**_ Nuke-users mailing list Nuke-users@support.thefoundry.**co.ukNuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.**uk/ http://forums.thefoundry.co.uk/ http://support.thefoundry.co.**uk/cgi-bin/mailman/listinfo/**nuke-usershttp://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users ___ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users ___ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users ___ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
Re: [Nuke-users] Re: ??? redguard1.glow ???
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/#findChannels
covers 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 list
Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
___
Nuke-users mailing list
Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
Re: [Nuke-users] cpp file
Thanks Howard. Works a treat. Ron Ganbar email: ron...@gmail.com tel: +44 (0)7968 007 309 [UK] +972 (0)54 255 9765 [Israel] url: http://ronganbar.wordpress.com/ On 18 April 2012 14:32, Howard Jones mrhowardjo...@yahoo.com wrote: One I had earlier- works in 6.3v7 Mac I think its the dylib version you want Howard -- *From:* Ron Ganbar ron...@gmail.com *To:* Howard Jones mrhowardjo...@yahoo.com; Nuke user discussion nuke-users@support.thefoundry.co.uk *Sent:* Wednesday, 18 April 2012, 11:32 *Subject:* Re: [Nuke-users] cpp file Thanks Howard! Ron Ganbar email: ron...@gmail.com tel: +44 (0)7968 007 309 [UK] +972 (0)54 255 9765 [Israel] url: http://ronganbar.wordpress.com/ On 18 April 2012 13:19, Howard Jones mrhowardjo...@yahoo.com wrote: I can have a look for you Howard -- *From:* Ron Ganbar ron...@gmail.com *To:* Nuke user discussion nuke-users@support.thefoundry.co.uk *Sent:* Wednesday, 18 April 2012, 10:49 *Subject:* Re: [Nuke-users] cpp file I see. Never done that before. Anybody compiled this for Mac and Nuke 6.3v7 already? Thanks R On Apr 18, 2012 10:08 AM, Peter Pearson pe...@thefoundry.co.uk wrote: On 18/04/12 06:59, Ron Ganbar wrote: Hi guys, just downloaded a file from Nukepedia (VectorTransform, cheers Johnathan) which is a .cpp file. Any idea how to install it? It's a source file for an NDK plugin - you'll need to compile it to a binary file for the platform you're on - or look for it pre-built somewhere... Peter -- Peter Pearson, Software Engineer The Foundry, 6th Floor, The Communications Building, 48 Leicester Square, London, UK, WC2H 7LT Tel: +44 (0)20 7434 0449 Web: www.thefoundry.co.uk The Foundry Visionmongers Ltd. Registered in England and Wales No: 4642027 __**_ Nuke-users mailing list Nuke-users@support.thefoundry.**co.ukNuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.**uk/ http://forums.thefoundry.co.uk/ http://support.thefoundry.co.**uk/cgi-bin/mailman/listinfo/**nuke-usershttp://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users ___ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users ___ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users ___ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users ___ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
Re: [Nuke-users] Re: ??? redguard1.glow ???
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/#findChannels
covers 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...
