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 < elias.ericsson.rydb...@gmail.com> 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 <blackenc...@gmail.com> > >> 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 >> Nuke-python@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python >> >> > > _______________________________________________ > Nuke-python mailing list > Nuke-python@support.thefoundry.co.uk, 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 Nuke-python@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-python
