Cool! Glad it helped. You might have noticed already, but if you want to take a look at the knobChanged code, keep in mind that it's baked into the gizmo itself. To get it back, you can do
print <aTimeMachineNode>['knobChanged'].value() Cheers, Ivan On Fri, Apr 6, 2012 at 12:44 PM, Christopher Horvath <[email protected]>wrote: > Hah - Ignore me, the information at the link provides both examples. This > is awesome. > > (That time machine gizmo is an amazing concept as well!) > > Chris > > > On Fri, Apr 6, 2012 at 12:42 PM, Christopher Horvath < > [email protected]> wrote: > >> Wow - thanks, Ivan, this is amazing and topical! >> >> If I was content to just let it be a Group - (fine for our purposes), how >> does one set that up? >> >> Chris >> >> >> On Fri, Apr 6, 2012 at 12:40 PM, Ivan Busquets >> <[email protected]>wrote: >> >>> Hi Chris, >>> >>> I believe there's 2 ways you can go about it: >>> >>> If you can settle for a maximum amount of slices you'd want to allow, >>> then it's probably easier to create your gizmo for the largest possible >>> case, and just disable/switch nodes based on the input values. >>> >>> If you do want the ability (as you have in Shake) to create the internal >>> nodes on the fly without the above limitation you'll need to work out a >>> combination of a knobChanged and onCreate callbacks. >>> The idea is to have a function that creates the internal nodes you need >>> based on, for exampel, a knob value, and then add that function to a >>> knobChanged callback so it's triggered every time you change that knob. >>> At this point, if you leave your gizmo as a group, you wouldn't need >>> anything else. >>> If you need to wrap it all in a gizmo, though, you'll need a second >>> callback to recreate the contents every time you reopen (or copy paste) >>> your node. The contents of the gizmo are not saved with the script, which >>> is why you would need this additional step. >>> >>> If you want a reference, have a look at this gizmo, which does dynamic >>> building of the internal nodes (also slicing) >>> >>> http://www.nukepedia.com/gizmo-downloads/time/timemachine/ >>> >>> I haven't looked at it in a while, and I "think" the onCreate callback >>> on that one broke at some point during the 6.2 release cycle. But it might >>> give you an idea on how you can set up your own. >>> >>> Cheers, >>> Ivan >>> >>> On Fri, Apr 6, 2012 at 12:25 PM, Christopher Horvath < >>> [email protected]> wrote: >>> >>>> Hello Nuke, >>>> >>>> I am trying to port a shake macro to Nuke and there's a difficult >>>> incompatibility. The shake macro splits an effect up into individual >>>> slices based on a min value, a max value, and an increment - so for >>>> example, if the values of these non-animatable knobs were >>>> {min=1,max=10,inc=1}, it would take the input node, create ten 'slices', >>>> each consisting of a few nodes chained together, and then finally combine >>>> all of these chains back together again at the end to produce the node's >>>> output. >>>> >>>> Is there a way I can do this in Nuke? There's examples in nukepedia >>>> from Frank Reuter showing how to conditionally create a TransformGeo or a >>>> Transform node, depending on the type of the input, but this only happens >>>> on node creation. I could conceivably build a little "re-slice" routine >>>> that is triggered from a button, and make it so that users have to >>>> explicitly set the slice parameters, which would, when executed, clean and >>>> re-build the underlying node tree. >>>> >>>> The shake macro looks like this: >>>> >>>> image shakeSliceThing( >>>> image input0=0, >>>> image input1=0, >>>> float sliceMin = 1, >>>> float sliceMax = 10, >>>> float sliceInc = 1, >>>> ) >>>> { >>>> float cur_slice = sliceMin; >>>> >>>> Result = DoSomething( input0, input1, cur_slice ); >>>> >>>> while (cur_slice<sliceMax) >>>> { >>>> cur_slice = cur_slice + sliceInc; >>>> Result = DoSomething( Result, image1, cur_slice ); >>>> } >>>> return Result; >>>> } >>>> >>>> Anyway - I'd love to hear if anybody has ideas about node-trees that >>>> depend on input values, or other ways to think about such a construction. >>>> >>>> Thanks, >>>> Chris >>>> >>>> -- >>>> I think this situation absolutely requires that a really futile and >>>> stupid gesture be done on somebody's part. And we're just the guys to do >>>> it. >>>> >>>> _______________________________________________ >>>> Nuke-python mailing list >>>> [email protected], http://forums.thefoundry.co.uk/ >>>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python >>>> >>>> >>> >>> _______________________________________________ >>> Nuke-python mailing list >>> [email protected], http://forums.thefoundry.co.uk/ >>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python >>> >>> >> >> >> -- >> I think this situation absolutely requires that a really futile and >> stupid gesture be done on somebody's part. And we're just the guys to do it. >> > > > > -- > I think this situation absolutely requires that a really futile and stupid > gesture be done on somebody's part. And we're just the guys to do it. > > _______________________________________________ > Nuke-python mailing list > [email protected], http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python > >
_______________________________________________ Nuke-python mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
