Thanks guys for the help and info!!

Jonathan: how do you do that internal hashing?

Cheers,
Cuco

On 21/11/11 18:49, Jonathan Egstad wrote:
I think in your case the append() route may work, since you’re creating the Blur in your op’s constructor. From what I can tell, the suggestion to use invalidate() (which again, I originally read in another thread) stems from use cases where the internal op tree isn’t actually constructed until _validate due to potentially varying numbers of internal ops, etc. Thus, if you were to create your Blur in _validate, there may not be an op to use as part of the parent operator’s hash at the time it is calculated.
Am I totally off base here?

I think that's correct Nathan.
Often the internal ops are being created in validate() since that's the earliest chance your op usually has at managing its internals - so invalidate() is the best option. I usually track the internal op's state manually with a locally built hash since I'm usually setting variables directly on them rather than using their knob interface (only possible on ops that you have a header for obviously.)

-jonathan


*From:* Jerry Huxtable <mailto:je...@thefoundry.co.uk>
*Sent:* Monday, November 21, 2011 12:23 AM
*To:* Nuke plug-in development discussion <mailto:nuke-dev@support.thefoundry.co.uk>
*Subject:* Re: [Nuke-dev] Internal trees of ops?
I haven't done this for a bit but I suspect you need to make sure that the hash for the blur op is added into your hash in the append() method, otherwise Nuke doesn't know that the blur knob has changed and won't call you Op again.
Jerry
On 20 Nov 2011, at 19:28, Cuco Bures wrote:

Hi guys,

Reading the documentation I found an interesting clue to follow... the internal trees of ops...

    (...) Many operators implement themselves by building internal
    trees of operators. (...)


Searching the forums and the web I couldn't find that much info about it. Found this topic in the Nuke's forums:

http://forums.thefoundry.co.uk/phpBB2/viewtopic.php?t=4948&sid=da7a57a7624d45adab48692dbdfd3afa

At the very bottom, Jonathan gives some good information, but I'm still missing something :(

Managed to put something together... It compiles, and if the size knob is set to a value other than 0 when the node is created in Nuke, it does blur the input, but never again. I mean, if you try to change the knob value, it doesn't change. The same if you do any changes in the upstream pipe (a grade before the node for example).

Obviously I'm doing something wrong... bear with me as I'm really new to the NDK (and C++ also).

Any help would be much appreciated!!

Cheers,
Cuco

P.S. The new Developers documentation is great, but would have been awesome to include some information about this!! Some working examples as well...

    // treeOpTest.C

    const char* const HELP =
      "Test PixelIop.";

    #include "DDImage/PixelIop.h"
    #include "DDImage/Row.h"
    #include "DDImage/DDMath.h"
    //#include "DDImage/NukeWrapper.h"
    #include "DDImage/Knobs.h"
    #include <string.h>

    using namespace DD::Image;

    static const char* const CLASS = "treeOpTest";

    class treeOpTestIop : public PixelIop
    {

      double size[2];
      DD::Image::Iop *blur;

    public:
      treeOpTestIop(Node* node) : PixelIop(node)
      {

        size[0] = size[1] = 100.0f;
        blur = dynamic_cast<DD::Image::Iop *>( Iop::create("Blur") );

      }

      void in_channels(int input_number, ChannelSet& channels) const;
      void append(Hash& hash);
      void pixel_engine(const Row &in, int y, int x, int r,
    ChannelMask, Row &);
      virtual void knobs(Knob_Callback);
      virtual int knob_changed(Knob*);
      const char* Class() const { return CLASS; }
      const char* node_help() const { return HELP; }
      static const Iop::Description d;

      void _validate(bool for_real);
      void _request(int, int, int, int, const
    DD::Image::ChannelSet&, int);

    };

    void treeOpTestIop::_validate(bool for_real)
    {
        copy_info();

    //    PixelIop::_validate(for_real);

        if (!blur) {
            blur = dynamic_cast<DD::Image::Iop *>(
    Iop::create("Blur") );
        }
        if (!blur) Op::error("failed to create internal op");

        blur->set_input(0, input0());

        blur->validate(for_real);
        info_ = blur->info();
    }

    void treeOpTestIop::_request(int x, int y, int r, int t,
    ChannelMask channels, int count) {
        blur->request(x, y, r, t, channels, count);
        PixelIop::_request(x, y, r, t, channels, count);
    }

    void treeOpTestIop::in_channels(int input_number, ChannelSet&
    channels) const
    {
        ;
    }

    void treeOpTestIop::append(Hash& hash)
    {
        hash.append(outputContext().frame());
    }

    void treeOpTestIop::pixel_engine(const Row& in, int y, int x, int r,
                                ChannelMask channels, Row& out)
    {
        out.get(*blur, y, x, r, channels);
    }

    void treeOpTestIop::knobs(Knob_Callback f)
    {
        blur->knobs(f);
    //    WH_knob(f, size, IRange(0, 100), "size");
    }

    int treeOpTestIop::knob_changed(Knob*)
    {
        if (knob("size")->get_value() != 0) {
            std::cout << "Size value: " << knob("size")->get_value()
    << std::endl;
        }
        return 1;
    }
    static Iop* build(Node* node)
    {
    //  return (new NukeWrapper(new
    treeOpTestIop(node)))->channelsRGBoptionalAlpha();
        return (new treeOpTestIop(node));
    }
    const Iop::Description treeOpTestIop::d(CLASS,
    "Test/treeOpTest", build);


_______________________________________________
Nuke-dev mailing list
Nuke-dev@support.thefoundry.co.uk <mailto:Nuke-dev@support.thefoundry.co.uk>, http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
Jerry Huxtable,
Senior Product Designer
The Foundry
Tel: +44 (0)20 7968 6828 - Fax: +44 (0)20 7930 8906
Web: www.thefoundry.co.uk <http://www.thefoundry.co.uk/>
Email: mailto:lucy.coo...@thefoundry.co.uk

The Foundry Visionmongers Ltd.
Registered in England and Wales No: 4642027

------------------------------------------------------------------------
_______________________________________________
Nuke-dev mailing list
Nuke-dev@support.thefoundry.co.uk <mailto:Nuke-dev@support.thefoundry.co.uk>, http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
_______________________________________________
Nuke-dev mailing list
Nuke-dev@support.thefoundry.co.uk <mailto:Nuke-dev@support.thefoundry.co.uk>, http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev


_______________________________________________
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

_______________________________________________
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

Reply via email to