Interesting. Thank you, Jonathan. Problem is, if Nuke has decided to render frame X through a non-first Iop, we don't really have the option to ignore it - the frame data will only be available to that version of the Iop, which may or may not be 'first'. No?
Steve From: [email protected] [mailto:[email protected]] On Behalf Of Jonathan Egstad Sent: Tuesday, May 15, 2012 10:02 AM To: [email protected] Subject: Re: [Nuke-dev] Re-construction Have you tried Op::firstOp() to see what it does? My impression is that this would always point at the 'main op' so you could have a single Op to rely on to store info, although there's no documentation of the method at all so it's all kind of a guess. This thread snippet from the nuke-dev archives may help (searching for 'firstOp' will show several threads that talk about multiple Op copies): Hi Abigail, Thanks for clearing that up - I'll give the firstOp() method a go! I did wonder what that firstOp() was for... unfortunately it appears to be missing some doxygen love in the NDK docs. cheers, dan On 04/01/2010, at 10:23 PM, Abigail Brady wrote: This is expected behaviour. You can also get multiple Ops per node if there are temporal accesses to you, for example. The 'main op' is returned by firstOp(), so you can compare with this. On Mon, 2010-01-04 at 16:28 +1100, Dan Bethell wrote: Hi all, I've noticed that if my Iop-derived node makes very frequent calls to asapUpdate() that multiple instances of it are constructed (copied I guess) by Nuke. If asapUpdate() is called less frequently nothing is constructed. The easiest way to see the behaviour is by using the Socket example from the NDK. If I put a debug print in the constructor and set the timeout knob to something very short I see multiple constructors being called. Is this expected behaviour? I expect this is just me not understanding what Nuke is doing behind-the-scenes with caching etc. The reason I ask is I have some global state which should only be configured once per node, and having nodes copied is causing a bit of a headache. I've been using an overridden attach() method to 'validate' the instances (which seems to work fine), but is there a better way to check if an instance of my class was created in this 'automatic' manner? Thanks, dan (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
