Jon, Thank you very much for your reply.
In response I can say that, yes, I have read the brief section in the NDK document describing 'Nodes vs Operators'. In fact, it was the first resource I consulted when I came upon this difficulty. Let me see if I can explain our difficulty in more detail There are certainly instances in which having multiple versions of an Op makes sense (multiple views, and your timeblur example are two), but there are also instances in which it is essential that Nuke *not* make copies. If I create an Op with a Render_knob, whose purpose is to scan a sequence to obtain some information from the frame data in it, having multiple versions of such an Op running at the same time makes things horribly messy. Do you see my point? I'm not contending that there are instances wherein multiple Ops are useful (caching not being one of them, by the way), but equally, there are instances in which guaranteeing only one Op is equally essential. Now I'm faced by trying to figure out how to create a custom, global nob that can be accessed by multiple Op instances while rendering a frame sequence. Steve From: [email protected] [mailto:[email protected]] On Behalf Of Jon Wadelton Sent: Tuesday, May 15, 2012 9:58 AM To: [email protected] Subject: Re: [Nuke-dev] Re: Re-construction Hi All, I think there is some confusion here about when ops are created. It's part of Nuke's architecture that multiple ops are created for a node. This is described here: http://docs.thefoundry.co.uk/nuke/63/ndkdevguide/intro/oparchitecture.html Ops are created for a few different purposes. The most common is to create a Node in the DAG, and for rendering at a given context. Sometimes the op used to create the node and the op used for rendering are the same.. but not always. For instance doing a timeblur will create multiple ops for rendering. Each with with their knob member variables frozen at a given context. Global data, parameters etc should not be stored on ops. They are stored on knobs, of which there is only one instance per node. If you really want to store global data outside a knob, which I don't recommend, you can store it by checking if your op instance is the first instance that Nuke created for making the Node. ( Op::firstOp() ). Also scrubbing/playing in the timeline can sometimes produce a new op used to draw or decide to draw overlay handles. Nuke does a cheap version of building the op tree for the purposes of drawing overlays if the current frame is in the viewer cache. If Nuke has not finished aborting a previous render this can result in a new op ( because it can't reuse the old one yet because its rendering ). Cheers, Jon. On 15/05/12 15:38, Steve3D wrote: Not good. I'm wondering how any node that displays frame data (the histogram, for example, gamma...) will ever work here with two different Iop's competing to update the UI. This is bad; this is really really bad. _______________________________________________ Nuke-dev mailing list [email protected]<mailto:[email protected]>, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev -- Jon Wadelton, Nuke Product Manager. The Foundry, 6th Floor, Communications Building 48 Leicester Square London, WC2H 7LT, Tel: +44 (0)20 7968 6828 * Fax: +44 (0)20 7930 8906* Web: www.thefoundry.co.uk<http://www.thefoundry.co.uk> The Foundry Visionmongers Ltd * Registered in England and Wales No: 4642027 (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
