Jonathan,
Thanks for the quick response. So... I added a Transform node after the 'Mirror' with a 'Size' of 1.01. I started at Frame 1, stepped to 2, then back to 1. I also added 'for_real' to the print statement in _validate. Here are the results: constructor, this: 95A6240 _validate, this: 95A6240, for_real: 1 Input frame: 1 Input view: 1 Output frame: 1 Output view: 1 _validate, this: 95A6240, for_real: 1 Input frame: 2 Input view: 1 Output frame: 2 Output view: 1 constructor, this: 20C59BD0 By the way, you were right; without the subsequent Transform node, Mirror's _validate does, in fact, get called with 'for_real' false first. This does not appear to happen with the subsequent node present. However, it also appears that Nuke does indeed re-instantiate the node with Transform after. I'm starting to feel a bit like Loki after meeting The Hulk :) What's worse about this is that I'm trying to create a node that gathers sequence-based statistics, using 'render_panel' and a 'Pyscript_knob', and about 20% of the time it ends up with two separate versions of itself handling the even and odd frames, which totally destroys the purpose of the thing. Steve -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Jonathan Egstad Sent: Sunday, May 13, 2012 7:23 PM To: [email protected] Subject: Re: [Nuke-dev] Re-construction > What the *HECK* is Nuke doing, constructing a *second* Mirror Iop on a > single-view Node? My guess is that it's the relatively new multi-frame caching system which is attempting to cache multiple frame's worth of Op tree data. If the input of Mirror was a Constant I doubt it would have created the add'l instance (I hope...) Try attaching something between the Mirror and the Viewer so that the Mirror doesn't end up owning an output cache and see if the behavior is the same. > Oh.. and P.S.? Why is it calling _validate twice on exactly the same data? > Something bizarre with the Viewer I expect. That I can answer definitively - check the state of 'for_real'. Nuke should call _validate(for_real=false) first so that an Op can get it's output configured correctly, then a second time with for_real=true for when engine() is about to be called so that the Op can prepare itself for data processing. Bill was never happy about the two-pass thing but we never came up with a better scheme that kept _validate() as simple as possible (we didn't want two separate virtual calls that did almost exactly the same thing most of the time.) -jonathan _______________________________________________ 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
