Or use uuid.
-jonathan
On Nov 21, 2011, at 10:15 AM, Nathan Rusch wrote:
>> 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
