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
