Adding in cc Foundry's support & the oracle (Jonathan). This oldie but goldie needs some love: it is just too common to have many channels in a node nowadays, and suddenly requesting multiple of them rather than the only one needed is a total waste.
Could some Nuklear Scientist @ Foundry assign a bug ID and look into this? Best, Paolo On Wed, Jul 28, 2010 at 6:16 AM, Moritz Moeller <realr...@virtualritz.com> wrote: > My plugin has a lot of channels users can request. Now I use a Shuffle > after to request individual ones while testing. > > Let say I request 'point'. > All fine, engine gets called with a mask set to 'point'. > > Next I switch the Shuffle to 'normal'. > Now I'd expect engine() to be called with a channel mask for 'normal' > but instead the mask is 'point,normal'. > > Likewise, if I now request 'motion' next, engine() will be asked for > 'point,normal,motion'. > However, if I now modify any setting on my plugin itself to force a > re-render, my engine() will correctly only be called with 'motion', as > one would expect. > > Wtf is going on here? > > I really like to find out how I can only render the channels that end up > being used. > Some of the channels my Iop outputs are literally 50times as expensive > as others. So in the not uncommon case that a user has started rendering > an expensive channel, switched the Shuffle to one of the cheap ones, > Nuke will still request the expensive channel (and the cheap one) from > my node, even though the former's data is never being used downstream! > > > I also noticed that if I call writable_channels() (undocumented)) on the > Row passed to engine() it will sometimes contain only contain those > channels that one would expect to be requested (i.e. 'motion' in above > example) -- but only sometimes. > But most of the time it is empty. So I intersect the mask passed to > engine() with row.writable_channels() if the latter is /not/ empty. And > that sometimes gives me what I expect -- sometimes. > > I'm looking forward to understand what is going on here. :) > > > .mm > _______________________________________________ > Nuke-dev mailing list > Nuke-dev@support.thefoundry.co.uk > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev > -- paolo berto jedi rock & dub band lead /*jupiter jazz*/ visual research — hong kong www.jupiter-jazz.com _______________________________________________ Nuke-dev mailing list Nuke-dev@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
