Not really. I had a discussion running here on the list a bit ago on the topic. I have different Requirements I guess. External references being one of them and that could Probably be made workable.
In addition I need to reference a set of nodes within the scripts to use it Many times in sync. They need to update live, automatically support adding/deleting Nodes, connections etc. Pretty much a cloneable group with some minor additions. Keep in mind that cloning still seems to be something to avoid in big scripts (talking 10k nodes+). Though we have not extensively tried with 7.x yet. Regards, Thorsten 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 >> -----Ursprüngliche Nachricht----- >> Von: nuke-python-boun...@support.thefoundry.co.uk [mailto:nuke-python- >> boun...@support.thefoundry.co.uk] Im Auftrag von Elias Ericsson Rydberg >> Gesendet: Donnerstag, 6. Juni 2013 04:29 >> An: Nuke Python discussion >> Betreff: Re: AW: [Nuke-python] Managing "referencing" of sub-scripts from a >> master script. >> >> 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.thefo >> > undry.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.rydberg@gmail. >> > com>> >> > To: Nuke Python discussion >> > <nuke-python@support.thefoundry.co.uk<mailto:nuke-python@support.thefo >> > undry.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.thefou >> > ndry.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.thefou >> > ndry.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.thefou >> > ndry.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.thefou >> > ndry.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.thefou >> > ndry.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.thefou >> > ndry.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 _______________________________________________ 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
