Thanks! Very revealing. From: [email protected] [mailto:[email protected]] On Behalf Of Jonathan Egstad Sent: Tuesday, May 15, 2012 11:02 AM To: Nuke plug-in development discussion Subject: Re: [Nuke-dev] Re-construction
Your comment about the original version of Nuke is fascinating, though. Was there no Pyscript_knob/render_panel back then? I ask because the current implementation assumes the 'beginExecuting / execute / endExecuting' structure pretty much assumes there is only a single instance of these being called. The current architecture was designed in 1999/2000 (Nuke3-beta) with TCL as its scripting language - I think Python had its first release in 2000. The original Nuke architecture was first designed in 1994-1996 and is basically the same to what you see today in terms of the Node/Op scheme. The main architectural difference in Nuke3-beta was abstracting Iops into Ops so that the 3D system could share equal footing with the 2D system (thanks Nafees!) So the base design schema of Nuke is nearly twenty years old. -jonathan Steve From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Jonathan Egstad Sent: Tuesday, May 15, 2012 10:39 AM To: Nuke plug-in development discussion Subject: Re: [Nuke-dev] Re-construction I don't want to speak for the Foundry, but I can say that the original Nuke design at Digital Domain did not offer the feature you're desiring. The original Nuke/DDImage architecture simply wasn't designed for that kind of interactive use. Think Houdini architecture vs Maya architecture. To do what I think you want has traditionally been done using singletons - aka how Sockets are handled. Messy and a pain I know, but it works. I used a singleton manager with maps of hashes to store prman render output shared between multiple engine runs and multiple Ops (for combined stereo rendering.) The hash used to look up the data is not the Op hash but derived from other info so that multiple Ops always get the same result. Good luck, -jonathan On May 15, 2012, at 10:18 AM, Steven Booth wrote: 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]> [mailto:[email protected]] On Behalf Of Jon Wadelton Sent: Tuesday, May 15, 2012 9:58 AM To: [email protected]<mailto:[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]<mailto:[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]<mailto:[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
