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…)
What Nuke’s doing under the hood is creating Ops for every Node in the graph, and possibly multiple ones at different frames and views. A Node can also create a number of Ops internally that it connects together. To save processing time during graph creation/updating Nuke tries to reuse previously allocated Ops depending on it’s previous hash value. This is all done by Nuke, not DDImage, and you have no visibility into this process from DDImage. btw, the use-case for using DDImage as an image engine outside Nuke around was for simple image processing tasks which accessed the built-in Ops like Read, Blur & Write (look for Op definitions that have static Description classes called out.) -jonathan On Dec 29, 2014, at 4:05 PM, Johannes Saam <[email protected]> wrote: > OHHH thanks for the answers!how do i call knobs()? As in what do i give to > it? it need Knob_Callback which typedefs to Knob_Closure which is abstract? > > Makes sense to call it... could we get a list to what is called when > sometime? This could make things like that easier! > > Then there is running only DDImage.... yeah i am kinda agreeing now that > without the NODE its kinda hard.... > about to ask another strange question in a new email! Thanks! > > On Mon, Dec 29, 2014 at 3:34 PM, Jonathan Egstad <[email protected]> > wrote: > 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 > > > _______________________________________________ > 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
