See also documentation for int Op::slowness () const, can help you.
2011/11/21 Georgiy Osipov <[email protected]>: > 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
