I'm not sure, but I think this is why the autowrite uses tcl as an intermediate step. Tcl updates all the time, python updates only when asked (right?). I think Frank Reuter talks about this in one of the free tutorials the foundry made available on youtube.
Does nodes in nuke re-evaluate python code when the node is "cooked"? I guess that if you re-submitted a script it would automatically do it as a new version for instance? 13 jul 2013 kl. 19:32 skrev Brogan Ross <[email protected]>: > Basically,we have a gizmo with a couple knobs, and a callback that would > update the path on the internal write knob when those values were changed. > Since it wasn't working, I added the knobs and callback to a Write node, so > we could just give people the Write with a couple extra controls. However, > once I put those knobs and the callback on the Write node, put the Write node > into a gizmo, and picked up the knobs it seems to render fine. Like I said, > I'm not sure why it works that way, but I'm glad it does. > > > > On Sat, Jul 13, 2013 at 6:55 AM, Diogo Girondi <[email protected]> wrote: >> Glad it now works, because It's hard to say what it might be without >> actually looking at what you're doing :) >> >> But usually when this happens is due to what I was talking about, a >> dependency with a knob that isn't being saved or re-set via a callback. >> >> Here I use a gizmo to replace the Write node which has basic options and >> get's it's settings from Shotgun. That way I ensure that a entire project is >> using the same settings no matter what and if I need to change something for >> some reason I don't need to inform people to change their write nodes, just >> re-submit their renders. >> >> >> Cheers, >> Diogo >> >> >> On Fri, Jul 12, 2013 at 4:35 PM, Brogan Ross <[email protected]> wrote: >>> Well, I'm not sure why this works, but it does. >>> I took the knobs that I was using as controls and added them to the write >>> node inside my gizmo, then picked them up onto the gizmo itself. If I get >>> a chance I'll poke around with it and see if I can figure out why it works. >>> >>> >>> On Fri, Jul 12, 2013 at 9:16 AM, Brogan Ross <[email protected]> wrote: >>>> Diogo, >>>> That doesn't seem to have helped. As soon as I read your response, I >>>> went 'oh duh', so I was surprised it didn't work out. Though, I know that >>>> the filename is getting set correctly on the internal write node because I >>>> have a callback that's creating the folders. >>>> >>>> >>>> Elias, >>>> We're actually trying to go the gizmo route this time. But, if I can't >>>> get this to work, then we'll have to do something similar to what you >>>> pointed out. We just wanted to give artist's a simplified ui for handling >>>> writes. >>>> >>>> >>>> On Fri, Jul 12, 2013 at 6:22 AM, Elias Ericsson Rydberg >>>> <[email protected]> wrote: >>>>> http://www.nukepedia.com/python/nodegraph/autowrite >>>>> >>>>> This is a different approach to the same problem. You can quite easily >>>>> modify it to fit your own directory structure. >>>>> >>>>> Cheers, >>>>> Elias >>>>> >>>>> 12 jul 2013 kl. 03:32 skrev Brogan Ross <[email protected]>: >>>>> >>>>>> I'm running into an issue with putting a Write node inside a gizmo. >>>>>> It's a pretty simple idea. Give the users some values to change, and >>>>>> run a knob changed callback to set the values on the internal Write node. >>>>>> >>>>>> It works when you keep it setup as a Group, but as soon as I covert it >>>>>> to a gizmo, I get errors when trying to do a cmd line render >>>>>> >>>>>> writeGizmo.writeNode: //path/to/files: has no valid channels - nothing >>>>>> to write. >>>>>> >>>>>> I've tried picking the channel knob and putting on the gizmo, creating >>>>>> an expression to the Write node's channels knob, and just leaving it >>>>>> alone inside the gizmo. But no matter what I get that error during >>>>>> render. I know it must be possible to do this, since other studios have >>>>>> done it, and it's even in the docs. Anyone have any suggestions on what >>>>>> to look into? >>>>>> >>>>>> Thanks >>>>>> _______________________________________________ >>>>>> Nuke-users mailing list >>>>>> [email protected], http://forums.thefoundry.co.uk/ >>>>>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >>>>> >>>>> _______________________________________________ >>>>> Nuke-users mailing list >>>>> [email protected], http://forums.thefoundry.co.uk/ >>>>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >>> >>> >>> _______________________________________________ >>> Nuke-users mailing list >>> [email protected], http://forums.thefoundry.co.uk/ >>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >> >> >> _______________________________________________ >> Nuke-users mailing list >> [email protected], http://forums.thefoundry.co.uk/ >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users > > _______________________________________________ > Nuke-users mailing list > [email protected], http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
_______________________________________________ Nuke-users mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
