Nuke also has a row cache. You should call void asapUpdate ()
for full frame or void asapUpdate (const Box &box, int direction=0) for region each time the hash is changed. 2011/11/21 Nathan Rusch <[email protected]>: >> From what I understand, it sounds like Nuke may be keeping your original >> op > > instances around and just re-calling append() on them. In this case, since > you're only seeding rand() in the constructor, wouldn't the subsequent calls > to rand() in the same context of that existing op give back the same result > for each instance? > > What happens if you call srand(time(NULL)) in append()? > > -Nathan > > -----Original Message----- From: Peter Kaufmann > Sent: Monday, November 21, 2011 2:38 AM > To: Nuke plug-in development discussion > Subject: Re: [Nuke-dev] Randomized Op hash > > If I clear the cache, it will recompute frames 1 and 2 just once. If I > toggle between them afterwards, it uses the cached images and engine() > is not called. My op inherits from Iop. > > Here's the complete code - there's not much going on really: > > /////////////////////////////////////////// > #include <time.h> > #include <DDImage/Iop.h> > #include <DDImage/Row.h> > > static const char *CLASS = "NukeHashTest"; > static const char *HELP = "Hash test"; > > class NukeTest : public DD::Image::Iop > { > public: > NukeTest(Node *node) > : DD::Image::Iop(node) { > srand(time(NULL)); > } > > // From Op: > virtual void append(DD::Image::Hash &hash) { > hash.append(rand()); > > std::cout << "New hash: " << hash.getHash() << std::endl; > } > > // From Op: > virtual int minimum_inputs() const { return 1; } > virtual int maximum_inputs() const { return 1; } > > // From Op: > const char *node_help() const { return HELP; } > const char *Class() const { return CLASS; } > > protected: > // From Op: > virtual void _validate(bool for_real) { > copy_info(); > } > > // From Iop: > virtual void _request(int x, int y, int r, int t, > DD::Image::ChannelMask channels, int count) { > input0().request(channels, count); > } > > // From Iop: > virtual void engine(int y, int x, int r, DD::Image::ChannelMask > channels, DD::Image::Row &row) { > std::cout << "engine..." << std::endl; > > DD::Image::Row rowIn(x, r); > rowIn.get(input0(), y, x, r, channels); > if(aborted()) > return; > > foreach(z, channels) > { > float *CUR = row.writable(z) + x; > const float *ptrIn = rowIn[z] + x; > const float *END = CUR + (r - x); > while(CUR < END) > { > float valIn = *ptrIn; > *CUR = valIn * valIn; > > ptrIn++; > CUR++; > } > } > } > > public: > static const Iop::Description description; > }; > > static DD::Image::Iop *build(Node *node) > { > return new NukeTest(node); > } > > const DD::Image::Iop::Description NukeTest::description(CLASS, > "NukeHashTest", build); > /////////////////////////////////////////// > > > Thanks, > Peter > > On 21.11.2011 11:10, Peter Pearson wrote: >> >> On 21/11/11 09:54, Peter Kaufmann wrote: >>> >>> Thanks for your reply. >>> >>> I'm calling srand(time(NULL)); in the constructor of the Op. So the >>> hashes are very likely to be unique. I also tried mixing a global int >>> variable into the hash and (atomically) increment that every time the >>> hash is computed. Same result. >>> >>> If I modify the inputs to my Op, then jump from frame 1 to frame 2 in >>> Nuke, both frames are computed as expected. However jumping back and >>> forth between frames 1 and 2 after that, new hashes are computed every >>> time, but engine() is not called again. >>> >>> Is it possible that the viewer is caching the data, ignoring the Op hash >>> for some reason? But then, why is the Op hash even being computing? >> >> If append() is getting called, it shouldn't be, as it's checked the hash, >> they should be different and the hashed data shouldn't be in the cache so it >> should call engine() on your op to get the new data and then stick that in >> the cache. >> >> You could try completely clearing your cache, but it sounds like something >> else is wrong... >> >> What class is your op inheriting from? Op/Iop/PixelOp? >> >> Peter > > _______________________________________________ > Nuke-dev mailing list > [email protected], http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev > _______________________________________________ > Nuke-dev mailing list > [email protected], http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev > _______________________________________________ Nuke-dev mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
