Kent, Why don’t you just pipe through the zDepth channel? That way it's in both out and in.
Steve -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Kent Martin Sent: Wednesday, June 22, 2011 2:21 PM To: Nuke plug-in development discussion Subject: Re: [Nuke-dev] Understanding requested channels... Greetings Abigail and The Foundry, I have just read this thread, and it is of high interest to me. I may have sent an e-mail several months ago dealing with a similar issue, but got pulled away from Nuke for quite some time. I am particularly interested in the comment about Nuke skipping the calls the _request and engine if the requested channels are entirely disjoint with the out_channels. (I actually found reference to this somewhere in the documentation, mentioning something about the intersection of in_channels and out_channels) I have been developing a node whose input contains only a Zdepth channel, but whose output is RGBA. Yes, the node functions but not very nicely within the Nuke interface. The node will only update when the viewer input is changed to Zdepth (which must trigger a proper "read") and back to RGBA ( so that I can see the desired output ). This makes the node, well, useless to an artist and leads to the following question : What is the proper method for dealing with this situation ? It is desired that the node update when knob values or time is changed without having to fiddle with the viewer settings. A "workaround" that has been implemented has the node reading "alpha" instead of "zdepth". A shuffle node follows the input image, shuffling depth to alpha, and a remove node then removes the depth channel. Ideally I would be able to read zdepth and output rgba. Setting the out_channels to rgbaz still requires the viewer to be set to zdepth, and back to rgba for proper update. Suggestions or guidance on more efficient and effective ways to accomplish conversion of depth to rgba will be greatly appreciated. Thanks, Kent Martin Production Engineer Blue Sky Studios ----- Original Message ----- From: "Abigail Brady" <[email protected]> To: "Nuke plug-in development discussion" <[email protected]> Sent: Wednesday, June 8, 2011 12:41:11 PM Subject: Re: [Nuke-dev] Understanding requested channels... More or less, although doing a separate Row/get for each passthrough channel would be inefficient - just add those to a channelset, and get them at the end, with only the copy in a foreach. On Wed, 8 Jun 2011 12:18:36 -0400, Colin Doncaster <[email protected]> wrote: > Thanks Abigail, > > So - if I understand correctly in engine I have to do > > foreach(z, channels) > { > if (userDesiredChannels.contains( z )) > { > // the plugin does it's thing > } else { > Row source( x, r ); > source.get(input0(), y, x, r, z ); > row.copy(z, source, z, x, r); > } > } > > where channels and row is the parameters of engine? > > > > -- > Colin Doncaster > Peregrine Labs > www.peregrinelabs.com > > On 2011-06-08, at 11:33 AM, Abigail Brady wrote: > >> You need to pass through the extra channels in _request and engine. >> Nuke will skip calling your _request and engine() in some limited >> circumstances, like if the requested channels are entirely disjoint >> with the out_channels(), but for example, in the case where it's >> asking for RGBA + creatureRGBA, you need to fill in both of them, it >> won't take your RGBA and then copy in creatureRGBA itself. (If it >> were to start doing that, it would mask out the channels you don't >> need to fill in when it calls _request/engine). >> >> On Wed, 8 Jun 2011 10:11:16 -0400, Colin Doncaster >> <[email protected]> wrote: >>> Hi there - >>> >>> I have an op that lets the user specify what channels should be >> affected, >>> let's say RGBA. When _validate is called I set_out_channels to the >> desired >>> channels and in request I input().request the desired channels. I >> assume >>> thus far this is correct? >>> >>> What happens when a user has an input image that contains a >> channel/layer >>> that hasn't been requested by my node? For example, the input image has >>> creatureMatte.r/b/g and I haven't requested them and/or included >>> them in >> my >>> output channels - does nuke just copy them to the output for me, should >> the >>> user expect to those channels to be maintained through the >>> processing of >> my >>> op or do I need to actually use Mask_All on validate and just pass >> through >>> the data in engine if that data is to be retained? >>> >>> If I don't retain it and the user is looking at that channel, what >> happens? >>> >>> Cheers >>> >>> -- >>> Colin Doncaster >>> Peregrine Labs >>> www.peregrinelabs.com >> >> -- >> Abigail Brady, Senior Architect >> The Foundry, 48 Leicester Square, London WC2H 7TW, UK >> Tel: +44 (0)20 7434 0449 * Fax: +44 (0)20 7434 1550 >> Web: www.thefoundry.co.uk >> >> The Foundry Visionmongers Ltd >> Registered in England and Wales No: 4642027 >> _______________________________________________ >> Nuke-dev mailing list >> [email protected], http://forums.thefoundry.co.uk/ >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev -- Abigail Brady, Senior Architect The Foundry, 48 Leicester Square, London WC2H 7TW, UK Tel: +44 (0)20 7434 0449 * Fax: +44 (0)20 7434 1550 Web: www.thefoundry.co.uk The Foundry Visionmongers Ltd Registered in England and Wales No: 4642027 _______________________________________________ Nuke-dev mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev _______________________________________________ Nuke-dev mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev (CONFIDENTIALITY NOTICE: The information contained in this email may be confidential and/or privileged. This email is intended to be reviewed by only the individual or organization named above. If you are not the intended recipient, or an authorized representative of the intended recipient, you are hereby notified that any review, dissemination or copying of this email, or the information contained herein is strictly prohibited. If you have received this communication in error, please notify the sender by return email and delete this email from your system. Thank You.)
_______________________________________________ Nuke-dev mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
