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.
_______________________________________________ Nuke-python mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
