and re:nathan yes i do have an Iop hooked to my node... crazy enough when i
view that node ( just a constant ) it must build itself properly as the
constant works... but even THEN i dont see anything on my iop pointer....
does nuke have several sets of nodes and i am accessing one thats just
dudd?? and never gets touched??

On Mon, 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

Reply via email to