> 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!) > > HA! Thanks for the timeline egg! So for people who have asked me why we didn't think of stereo caching issues. Now you know! It's because around 2001 stereo movies were still just that gimmick from the '50s.
-n > So the base design schema of Nuke is nearly twenty years old. > > -jonathan > > > **** > ** ** > Steve**** > ** ** > ** ** > *From:* [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]] *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], 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**** > **** > 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**** > > ** ** > > > (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 > > > > _______________________________________________ > 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
