Oh I also forgot to mention that if I was starting over from scratch (which I am half heartedly considering) I would do it all completely differently:
This is what I sent to Shotgun Software: http://i111.photobucket.com/albums/n134/im_thatoneguy/ShotgunNodes.gif So my basic philosophy going in was to address a couple fundamental challenges: - Exposing the shotgun data to scripting. - Maintaining consistency between various Shotgun<->Nuke integration efforts and Deadline's integration. - Streamlining and standardizing the user experience. With those goals in mind I took the parts I like from the Deadline integration, mainly the unified Entity Browser but tried to think of ways to better use that data. There are a number of ways in which a Nuke Script can interact with Shotgun. You could read notes for instance on your shot. Maybe having a node to right inside of nuke review all of the feedback to make comp changes. You could use Shotgun to link to Deadline rendered file paths to read in render pass versions. You can use Nuke to review render element versions and make notes to the 3D department with glitches "GI Flicker @ Frame 100". The ways in which Shotgun and Nuke can be leveraged are extensive, but at present each and every script or tool has to re-invent the wheel in order to function. If I have a shot note, read node and deadline system all in one script I have to specify "What Shot is this?" 3 times. I also have to provide my Shotgun Username 3 times and so on and so forth. So there needs to be a single unified repository for this information. When someone is setting up a Nuke comp they should only need to enter in the Shot Meta-Data once. They should only need to log-in once (I'm not really happy with that bit but I'll get to that in a minute as well). And they definitely shouldn't have to specify the shot every time they add a Sg (Shotgun) aware tool such as a read node or submit a script to Deadline. Yes, deadline can pretty easily store in an INI file all that information, but it should be carried within the script--and it should be easily exposed within the script. But there's another challenge, while sometimes you might only have one shot/output per script--sometimes you have different shots and outputs within the same composite. In this case a universal Sg setting wouldn't work. Similarly, sometimes you read in render elements from different shots. Maybe you rendered off a few explosion elements for Shot '0020' but you want to use it in Shot '0030'. Maybe part of your composite will be used in a couple shots so you keep them in one comp. Regardless of the reasons, a single global shotgun link per Nuke Comp isn't going to be a good long term solution, eventually there'll need to be a per-tree 'override' for defaults in addition to local ones. Another challenge is that you don't want to be hammering your Shotgun server every 2 seconds. Most of the time you just need to pass along the Entity GUID so that future queries know what to request. For example, if you had an sgEntity node at the root of your comp and submitted to deadline you wouldn't even need to use the Entity Browser. Assuming the GUID passed down was still valid that's all that would need to be passed as meta-data to the Repository. I do like the Deadline concept of having a single Shotgun Entity Browser. I like it so much that I think Shotgun should write one which is unified and open to all shotgun integration efforts. I believe it needs to return just 4 things: Entity Type, GUID, Plain-text Name and Plain-Text Entity-Type. Everything else could be queried easily through scripting from that data. Most tools would need a button which launches the Shotgun Entity Browser. But they could also walk up the node-graph and find a sgEntity node and just steal its 'cached' copy. I think Shotgun integration efforts would benefit from Shotgun defining the node structure and offering a Python Module for Nuke which would enable a variety of tools to use a single unified repository for shotgun settings. I know that Thinkbox is concerned about fragmenting their user experience, but with this system you wouldn't need to worry about that. You could still have the exact same UI you have now, the only difference would be that you would also check to see if there is an "override" in the composite/scene that has already defined the settings. So when you launch the Deadline Submission script in the short-term it could just check the composite, see if there are any shotgun nodes and if so, pre-fill the fields accordingly. If not--no harm no foul, the user uses the slower and less efficient universal Deadline experience. After all, the only point of the whole shotgun window for deadline is to aquire: Entity Type & GUID and Version Name. There is no reason you couldn't just pull that from a node in the script instead of the pop-up window. Or you could use the Pop-Up window. The deadline submission script shouldn't care where it gets those 3 pieces of information from. Similarly it would be trivial to pull the username and prepopulate the field from a scene node. Now going back to the username for a second. There was some discussion before of linking the Shotgun Username with the Deadline username. Not terribly fond of that since I have a different Deadline username from Shotgun username. System Username seems like the most reliable and consistent system. But again there is no reason Thinkbox should have to worry about that. If Deadline pulled the username from a Shotgun Software defined standardized "Settings" node (or root.knob in the script settings node ('S') then different studios would just need to write little startup scripts which auto-filled the shotgun node with the current user. Maybe when you open a script you already have a script which automatically checks the script out. It can at the same time also find and fill out a ShotgunSettingsNode.knob('sgUsername').setKnob(studio.getCurrentSgUser()) (forgive my made up Nuke Python I can't do off the top of my head). Deadline doesn't have to worry about that. If it finds a node with a hidden knob called something like "ShotgunSettingsNode" it just knows it needs to pull the sgUsername field. Easy peezy! Similarly if eventually Shotgun provided a more universal Shotgun Entity Browser which just returns the aforementioned 4 important pieces of information (or more, 4 is the minimum I believe, certainly not the maximum) then Deadline could just call that with maybe a launch flag specifying what it's requesting and Shotgun could continue to update the Universal Entity Browser without Thinkbox having to continually update their browser. Deadline would upgrade automatically as the Shotgun SDK upgrades. http://i111.photobucket.com/albums/n134/im_thatoneguy/Shotgun_Mini-Project_Browser.gif http://i111.photobucket.com/albums/n134/im_thatoneguy/Shotgun_Mini-Entity_Browser.gif - Gavin On Wed, Dec 14, 2011 at 10:14 AM, Gavin Greenwalt <[email protected]>wrote: > I wrote a read node which would find the latest elements for a shot. > > http://www.vfxtalk.com/threads/21217-Shotgun-Read-Node-(SG-Integration) > > But it was written in '09 and hasn't been updated since so you probably > will need to tweak the SG API calls. > > - Gavin Greenwalt > Straightface Studios > > > On Wed, Dec 14, 2011 at 8:52 AM, Gerard Keating <[email protected]> wrote: > >> Hi, >> Have you seen shotgundropper >> http://www.nukepedia.com/python-scripts/nodegraph/shotgundropper/ ? >> We use a custom version of this and it works great. >> Regards, >> Gerard. >> _______________________________________________ >> Nuke-users mailing list >> [email protected], http://forums.thefoundry.co.uk/ >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >> > >
_______________________________________________ Nuke-users mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
