And one other thing... I can't imagine a case in which it makes sense to instantiate a second instance of an Op to do caching. There are a thousand use-cases in which this would create nightmares. Anything that is temporal-aware will break. Anything that splits an input on frame. Anything that uses another view; the list goes on and on. Further, which node is connected to the knobs? How are they serialized?
This whole thing just makes no sense, and feels very much like a bug to me, but then I may not truly understand what's going on. 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], 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
