Are you calling Op::knobs() at any point? That’s really required previous to calling validate() in order for the Knobs to store their values into the Op.
Re. running only with DDImage - I think you’ll find it very difficult to get most Iops working without DDImage resident since there’s a number of built-in static vars that are relied upon to be present and configured like Channels and Formats. Even with DDImage loaded it’s pretty tough to get an Op loaded and configured without Nuke present since the Node class is undefined in DDImage and there’s a number of blind callbacks to Node implemented in Nuke called by DDImage. And then there’s all the Knob callbacks that need to be implemented... -jonathan On Dec 29, 2014, at 2:56 PM, Johannes Saam <[email protected]> wrote: > i tried Op::force_validate( true ) btw no luck > > On Mon, Dec 29, 2014 at 2:33 PM, Johannes Saam <[email protected]> > wrote: > Thanks guys! > Let me be more specific... its all very theoretical sorry... > > > so the first issue i have is that when i have an Op* in nuke and use it > outside the regular context i dont get it validated. So imagine i have an > Iop* store it in a list and then at some point ( nuke has not done anything > besiuds running and showing the interfacce ) i wann access the parameters of > that Iop* using ->format() for example... i am calling validate( true) on the > Iop BUT the Iop has no valid data to read. The pointer is valid though > because things like accessing the name Knob work or printing the Class() so > thats working but the node wont validate outside the regular validate inside > my plugin... soooo how do i validate the Iop properly with all its ins and > outs.... > Then the next level is to use that node to compute stuff.....re: Colin i > wanna try both... with nuke running i could feed it input data ( i hope > somehow ) and then compuite it using the engine ? Best would be to just link > against DDImage and not even have to run nuke... but thats the next next step > :) I am just trying to see how far i can push this... but first validating > the Iop ( or cameraOp or whatever ) PROPERLY form the outside would be > cool.... > just try making an std::vector<Iop*> and store it as a member and then at > some other point lets say in build_handles() iterate over the list and print > all the Iops resolutions.... or even better access the pixel data .... HOW?>! > The shared memory idea for i/o sounds doable in theory but would be rather > ugly dont you think? > Thanks guys! > > On Mon, Dec 29, 2014 at 12:28 PM, Pierre Jasmin <[email protected]> wrote: > > In theory, you could make a shared memory node as a nuke operator, and call > Nuke command line from another program, have the ShMem node callback to do > what you have to do ... > > Pierre > > > On 12/29/2014 11:21 AM, Colin Doncaster wrote: > Do you mean outside of Nukes evaluation but still within the application or > do you want to link against ddImage.so and call Nuke Ops? > > On Dec 29, 2014, at 1:46 PM, Johannes Saam <[email protected]> wrote: > > Hey ! > > Merry christmas everyone :) > I have a little bit of an RnD theoretical question.... > Could we use nuke ops outside nuke? Meaning could i have an Iop input that i > call validate request and engine on myself and feed it data? And of course > get the data afterwards? Meaning could i use a nuke blur or even better a > nuke network and use it to process other data that i specify? > > Its more of a theoretical one but any thoughts are greatly appreciated. > > Rock on > jo > _______________________________________________ > 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 > > > _______________________________________________ > 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
