Well, the problem I see with gizmos is that they don't update. I don't know if you can dive into the script in the precomp node, but with a little python I think you could add a button to open the script in a new nuke session.
Being able to dive in would be very similar to Houdini, also having gizmos that update (HDAs). 2013/6/5 Christopher Horvath <[email protected]> > The problem is that the precomp node doesn't allow for easy introspection > of what's contained inside it, and it only allows for a single output. > Which, I guess, is also true of the gizmo solution. Is it possible to dive > into the script that the precomp node references, and make changes? With a > gizmo, you can copy the gizmo to a group - at which point the dynamic > nature of the reference is broken, but that's okay. > > Basically, I'm hoping there's something that's really similar to the > referencing idiom in Maya, where it's clear when a node is referenced, and > there are tools for importing or switching references. > > > On Wed, Jun 5, 2013 at 2:00 PM, Elias Ericsson Rydberg < > [email protected]> wrote: > >> So the precomp node doesn't do what you're after? One precomp node per >> asset, link them together in the master file. Isn't that what you're trying >> to do? >> >> >> 2013/6/5 Christopher Horvath <[email protected]> >> >>> Hello Nuke Python developers... >>> >>> I'm investigating whether it's possible to support a referencing >>> workflow, similar to maya's, in a nuke script. The idea would be that >>> there's a master script for a shot or sequence, which references in >>> separate scripts that contain the treatment for a particular asset or a >>> particular element in the shot or sequence of shots. >>> >>> The goal is to be able to publish the individual subscripts >>> independently as part of a production process, and have the master script >>> pick up the published changes. This will facilitate the ability to make >>> changes across many shots at once, that sort of thing, and also workflows >>> wherein one department can work on their elements without disturbing the >>> work of another department, and clobbering each other's scripts. >>> >>> In terms of what's already available - obviously it's possible to simply >>> manually import one script into another, though this would be difficult to >>> keep synchronized after the first import. The "Precomp" node allows a sort >>> of "blind" import of an external script, but with only one output. >>> >>> I've considered simply using the gizmo, or "groupzmo" idiom as a way of >>> hijacking script portability. We can just export a script as a gizmo, >>> change the gizmo to group, and then publish that with a shot-specific or >>> sequence-specific name. The master script can then just import the gizmo, >>> and even make it editable if necessary, but if no modifications are made, a >>> new publish of the gizmo will be picked up by the master script. >>> >>> The only other thing I've considered is whether or not you could build >>> some sort of ornate referencing tool using onScriptLoad callbacks, though >>> I'd need to be able to parse and instance a nuke script from inside python. >>> >>> How have other people solved these types of pipeline problems? It seems >>> like the "treat references as gizmos" idea is the most simple, but I'm >>> curious if there are other options. >>> >>> 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 > >
_______________________________________________ Nuke-python mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
