Hey all, So, nope, you won't be able to use DDImage outside of Nuke for sure, for the reason Mr Egstad mentions and more.
You have to be very careful using Op pointers in this way as they will get destroyed and created at whim by DDImage so you might very well end up with a a dangling Op*. In fact you probably don't want to do this at all. I'll have a bit more of a think but I'm not sure you can do what you're trying to do, at least not with DDImage as it is. What I suspect you really want to do is generate and manage your own Op-graph (not just Ops) for your context, but I'm not clear on what we expose to allow you to do that, of the top of my head, but it is something we should allow. Sorry I can't be more helpful. Out of interest, what are you trying to do? F. On 31 December 2014 at 02:24, Johannes Saam <[email protected]> wrote: > Soooo after some time of going CRAZY i found that it must be somewhere in > my compiler settings.... a simple scenario gets me worng results > > MyOp::validate( bool real ) > { > Iop* image = dynamic_cast<Iop*>(Op::input(0)) > if ( image ) > { > image->validate(true); > std::cout << image->w() ------- WRONG OUTPUT!!! > .... > > the same code in a different simpler VS project works as it did for > YEARS.... so i must somewhere miss a compiler flag or something but this is > super strange... everything SEAMS to work just the data is garbage > > i keep you posted but this is one strange one... > jo > > On Tue, Dec 30, 2014 at 2:22 PM, Johannes Saam <[email protected]> > wrote: > >> Ok sooooo that did not change a thing... >> >> in validate i copy the Iop* to a vector and then in build handles i call >> setKnobsToContext( Op::output_context() ) and force_validate... no luck... >> by no luck i mean iop->w() is not initialzied and the format pointer >> empty. >> >> I was now serisouly wondering... so i did a test in my actual validate! >> And even THERE i cant get a proper output?! Its the first time i derive >> from Op directely and dont use the Iop or deepOp or GeoOp classes is there >> anything i would miss by not having an Iop derived class?! I used the >> SimpleOp example to guide me... i am Implementing doAnyHandles and all the >> drawing and it does work... i am really confused now :) >> >> Thanks for your help! >> Jo >> >> On Tue, Dec 30, 2014 at 1:45 PM, Johannes Saam <[email protected]> >> wrote: >> >>> I am trying that right now... what is the right way to own the pointer? >>> calling Op::Input(i) and then casting it? Thats what i do in validate so >>> far... i would like to do it anywhere but i am not sure when the Op pointer >>> is actuially valid. >>> Stend by for the test >>> >>> On Mon, Dec 29, 2014 at 5:25 PM, Jonathan Egstad <[email protected]> >>> wrote: >>> >>>> What about using Op::setKnobsToContext() before calling >>>> Op::force_validate()? >>>> This seems like that's what you’re trying to do if you truly own the Op >>>> pointer. >>>> >>>> -jonathan >>>> >>>> On Dec 29, 2014, at 5:00 PM, Johannes Saam <[email protected]> >>>> wrote: >>>> >>>> Interesting! I check that out... >>>> i am still stuck on my case... so i am NOT outside nuke.... I just >>>> wanna use the values of an Iop ( and otheres ) to be accessible in my >>>> plugin outside the beaten path.... >>>> >>>> copy pointer to somwhere >>>> later access the Iop basics >>>> >>>> but i can never ever get the validate to run properly... and no calling >>>> knobs() wont work. >>>> >>>> Damn i just want to validate a node on its own.... is it just not >>>> possible to save pointers?? In _validate i copy the pointer and even >>>> validate the node here.... but my pointer never gets valid...i might just >>>> have to copy copy the values there but then i loose the connection... that >>>> would be lame! >>>> >>>> On Mon, Dec 29, 2014 at 4:46 PM, Jonathan Egstad <[email protected] >>>> > wrote: >>>> >>>>> On second thought, to be honest I don’t think you can realistically >>>>> call Op::knobs() from outside Nuke without significant trouble - >>>>> Op::knobs() needs to be called twice, first to have the Op create the knob >>>>> objects then to have each knob object store. You implement two subclasses >>>>> of DD::Image::Knob_Closure - one configured as a knob creator and one as a >>>>> knob storer. BUT - this is exceedingly non-trivial and is not intended to >>>>> be done by a plugin developer as you’ll need to support all the various >>>>> knob callback macros which is just not practical…) >>>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 > > -- Frank Harrison Senior Nuke Software Engineer The Foundry Tel: +44 (0)20 7968 6828 - Fax: +44 (0)20 7930 8906 Web: www.thefoundry.co.uk Email: [email protected]
_______________________________________________ Nuke-dev mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
