This feels like a very large amount of work to get this kind of functionality! If the gizmos had the ability to have multiple outputs, and there was an easy "rehash" capability for refreshing gizmos and finding new ones, I think that would cover the bases very generically, without imposing a particular pipeline structure or topology.
Chris On Wed, Jun 5, 2013 at 7:29 PM, Elias Ericsson Rydberg < elias.ericsson.rydb...@gmail.com> wrote: > 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 > -- 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
