Cant you just use the open button to open the precomp?
What about backdrops - could you bring in a script in a backdrop - keep version
info in the backdrop label (script name etc) and on open search each back drop
then replace with the latest script.
No idea how to script it but might be feasible?
Cheers
Howard
________________________________
From: Elias Ericsson Rydberg <elias.ericsson.rydb...@gmail.com>
To: Nuke Python discussion <nuke-python@support.thefoundry.co.uk>
Sent: Wednesday, 5 June 2013, 22:14
Subject: Re: [Nuke-python] Managing "referencing" of sub-scripts from a master
script.
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 <blackenc...@gmail.com>
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
>
>
_______________________________________________
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
