I think Howards idea of using backdrops is interesting. On import of the child/asset/sub-script, select the new nodes, create a backdrop. And as Howard said, put the version, path to original script, creator etc in it. Why not create an extra tab, put the info in fields there and use tcl in the label instead.
If you use shotgun, ftrack or any other system like it I imagine it shouldn't be too hard get the same information from there. Next step would be to have python compare version numbers to make sure you're using the latest and greatest. I guess you could also compare the nodes inside the backdrop with the ones in original (the child) nuke-script. If they are different you may want to alert artists of it, why not change the backdrops color to red for example. Like Howard said. Now, if you make edits in the backdrops of the master/parent script you may want to save the contents of the backdrop as a new version. This functionality could be on the tab we added to the backdrop node, I imagine a "save new version" button. Although this isn't fully live, it's on par with Maya references. Except it checks against published version, while in the precomp you would just need to re-save the child and update the parent. Could that work for you? Cheers, Elias Ericsson Rydberg 6 jun 2013 kl. 00:10 skrev Thorsten Kaufmann <thorsten.kaufm...@mackevision.de>: > On my end i'd need things to be live. As mentioned a cloneable group node > kind of thing would do the trick basically. More sophisticated would be > better ;) > Thorsten Kaufmann > Head of Production > ____________________________________ > > Mackevision Medien Design GmbH > Forststra?e 7 > D-70174 Stuttgart > > T +49 711 93 30 48 59 > F +49 711 93 30 48 90 > M +49 151 19 55 55 02 > > thorsten.kaufm...@mackevision.de > http://www.mackevision.de > > Gesch?ftsf?hrer: Armin Pohl, Joachim Lincke, Karin Suttheimer > HRB 243735 Amtsgericht Stuttgart > ________________________________________ > Von: nuke-python-boun...@support.thefoundry.co.uk > [nuke-python-boun...@support.thefoundry.co.uk] im Auftrag von Elias Ericsson > Rydberg [elias.ericsson.rydb...@gmail.com] > Gesendet: Donnerstag, 6. Juni 2013 00:00 > An: Howard Jones; Nuke Python discussion > Betreff: Re: [Nuke-python] Managing "referencing" of sub-scripts from a > master script. > > I forgot the "open" button on the node. Silly me. > > What assets are we talking about here? eg. having a roto task done in > separate script? > > > 2013/6/5 Howard Jones > <mrhowardjo...@yahoo.com<mailto:mrhowardjo...@yahoo.com>> > Or at least flag each out of date backdroped script for manual fixing? > > Cheers > Howard > > ________________________________ > From: Howard Jones <mrhowardjo...@yahoo.com<mailto:mrhowardjo...@yahoo.com>> > > To: Nuke Python discussion > <nuke-python@support.thefoundry.co.uk<mailto:nuke-python@support.thefoundry.co.uk>> > Sent: Wednesday, 5 June 2013, 22:31 > > Subject: Re: [Nuke-python] Managing "referencing" of sub-scripts from a > master script. > > 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<mailto:elias.ericsson.rydb...@gmail.com>> > To: Nuke Python discussion > <nuke-python@support.thefoundry.co.uk<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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<mailto: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
