Maybe use channel layers for multiple outputs? On 6 Jun 2013 23:42, "Christopher Horvath" <blackenc...@gmail.com> wrote:
> 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 > >
_______________________________________________ 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
