Hi Steven,
If you want to do an analysis pass over a sequence like you're
describing your plugin class should implement the Executable interface
and then the user should 'render' or click a button on your panel than
renders your node over the given sequence. Then you can store the
results on a knob or the first op. Another op maybe created and
running during your analysis for rendering or drawing handles but at the
present time Nuke only let's one 'Executable' happen at a time.
http://docs.thefoundry.co.uk/nuke/63/ndkdevguide/split-and-execute/executable.html
Cheers,
Jon.
On 15/05/12 18:18, 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]
<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
--
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
_______________________________________________
Nuke-dev mailing list
[email protected], http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
