1

example workflow for handling 'scans' in SG and Tank

Abraham Schneider

July 28, 2015 16:14

None

Follow

Hi there!

While looking at your current apps, especially the tk-multi-loader, one thing immediately came to my mind: using this loader in Nuke (and other apps) to not only load things that have been rendered and published before in another app but also to load the 'scans'/footage for the shot.

 

It would be very useful as a starting point for own development to have a sample workflow/instruction, how 'scans'/original footage could be cleverly managed in Shotgun and then be loaded by the tk-multi-loader. Let's say I get a folder with 'scans' (or onlined/converted/debayered footage) from the I/O department, how could I add them to Shotgun and use Tank to move them to their desired location in the shot folder structure and make them loadable from the tk-multi-loader in all the apps that support this app?

 

Abraham

• Facebook
• Twitter
• LinkedIn

11 comments

• 0
  
  Rob Blau July 28, 2015 19:16

  Hi there Abraham,

  Thanks for bringing up the whole ingest workflow.  It is one that we're definitely thinking about and trying to figure out how soon we can tackle it.  In the shorter term, we have a publish app for the shell engine (tk-shell-publish) that could be extended to support image sequences which creates the data in Shotgun that the multi-loader can load (I've created a ticket for us to make that change).  That app needs the files to already be in a location that Tank can associate with a Shot for the publish to be linked up correctly, so there would need to be a new app (likely for the Shotgun engine at this point) that could take a plate and associate it with a shot, copying/linking the files into a shot specific directory.

  Our long term plan for this workflow involves some work happening in Shotgun, Revolver, and Tank to have better cut support.  We are planning on being able to represent the equivalent of an EDL in a standard way in Shotgun and putting together an app that will be able to populate a cut and its associated Versions in Shotgun from a set of plates and associated editorial information.  With that rich data in Shotgun we would be able to handle plates being used across different shots, retimes with plates, and other scenarios that tend to come up.  We picture the loader app for scans (or plates, or lineups, or count sheets; pick your nomenclature) being able to not only create the read nodes for the footage without needing to move it on disk, but also to set up curves to map the input frame range for a plate to the output frame range for the shot.

  -r

• 0
  
  Abraham Schneider July 28, 2015 19:16

  Shell engine? What's that going to be/capable of?

  All the rest sounds great!

• 0
  
  Rob Blau July 28, 2015 19:16

  It is an engine for use inside of a python interpreter, to be able to launch Tank apps from the command line.  We'll be putting polish on it and getting it wrapped up so that there is a standard way to get at Tank goodness for people in the terminal.

  There should be more on that front and on the designs for cut support early in the new year.

  -r

• 0
  
  Milan Kolar July 28, 2015 19:16

  This idea should definitely be implemented and expanded for general publishing of external files. The option we've come up with so far is having a standalone publish app or a proper shotgun integrated publish app. This would be the used for any type of odd files that come to production from outside. Be it plates, textures, matte paints, model... If we need to publish anything that wasn't done in an app that has tank engine, it needs to be done one by one in shotgun and as you said, it needs to be already in place. The kind of workflow we'd like to be using is something like this.:

  1. The app scans a folder to digest and shows a list of available files (based on user choice e.g. .ma, .exr, .dpx ....)
  2. user can fill out some basic info in the fields for these files (project, category ...)
  3. app takes this info and based on it, moves the files to their correct locations, creates assets in SG and links to their corresponding tank published files.

  The reason I'm generalising this so much is because this would also partially solve the problem with people working externally. They could just upload files they want to publish into an ftp folder (a this can really be a wild selection of types of data), this App picks them up and publishes to SG and tank. I can easily imagine that it could even pre-populate the fields by guessing from file names based on given naming conventions. 

  Milan
• 0
  
  Abraham Schneider July 28, 2015 19:16

  Very good addition Milan, thanks!

• 0
  
  David van Heeswijk July 28, 2015 19:16

  Good ideas! Our workflow looks like this currently: Scans are rendered out through our Assimilate Scratch system. A custom Python script sets up all the Nuke scripts based on what comes out of Scratch and sets all the render locations in the Nuke write nodes. A custom Nuke menu opens the script. So being able to link pre generated Nuke scripts to Tank could also fit in this picture. I'm saying this because we are also looking at Hiero. Since Hiero does pretty much the same thing. But maybe Tank could also handle the whole script setup part in the future? Looking at dpx sequences and then set all the read and write nodes accordingly.
• 0
  
  Rob Blau July 28, 2015 19:16

  Hi all,

  We are currently working on the Hiero engine and a simple implementation of a Hiero workflow similar to what you are talking about.  No
  timeline on that yet, but it is under active development. That Hiero workflow is the first workflow we're tackling that would take plates/scans and publish them to shotgun and get your shots setup to work on them (including creating those Nuke scripts). It is possible to implement a set of apps that would work outside of Hiero to accomplish a similar thing, but we're going to see how everybody responds to the Hiero workflow before deciding how/when to do that.

  Additionally, the shell engine has been tuned up for use in this week's release. While we don't yet have that generic publish tool (it is on
  the list), that shell engine provides a great foundation to build an app like that and have all the functionality of Tank available.

  Are there any other studios interested in these workflows? Do the flows described above sound like a match to your own way of doing things?

  Thanks for all the feedback and ideas! Keep 'em coming!

  -r

• 0
  
  David van Heeswijk July 28, 2015 19:16

  Hi Rob, We've been testing the Hiero engine since it's release and it saves so much time allready. However, there are 2 main things that we think can be realy usefull. - the generated Nuke scripts don't yet get published. So we have to publish them with a script. I'm saying this because we just want to minimise human error (file naming etc) and the v001 scripts to be available via the Shotgun file manager. - since we use Hiero as a hub for rendered shots from our Scratch system, an option to just publish plates straight from the timeline would be awesome. No rendering, just plain publishing of lets say DPX files. In Nuke artists can then simply bring plates in via the render loader for instance. That way plate publishing becomes much easier. Just my 2 cents... Cheers! David
• 0
  
  KP July 28, 2015 19:16

  Hey David,

  Great to hear you guys are using the Hiero integration and it's saving you time! We're currently working on getting the Nuke scripts published (with toolkit write nodes) as part of the export process so hopefully you'll see that very soon. This was always the plan, we just wanted to share what we had so far so we could start getting feedback!

  Can you explain a little more about the workflow you'd like to see regarding the plate publishes? Would love to hear more about what would make life even easier.

  kp

• 0
  
  David van Heeswijk July 28, 2015 19:16

  Hi Kp, Great to hear you guys are allready working on the script publishing! A massive timesaver! Regarding the plate publishing. Our plates are allways being rendered in our Assimilate Scratch system. So we bring those into Hiero and run the Shotgun exporter. However, The plates don't have to be rendered twice and we never use Quicktimes in Nuke (inefficient and slow). We just like to publish them "as is" to Shotgun. Say we want to re-use plates in other shots, which happens a lot in episodics, then it would be usefull to just publish the plates to Shotgun and be able to easily load them (as an asset or as a render) via the Shotgun File manager. Hope this makes sense. Cheers!
• 0
  
  Tzuen Wu July 28, 2015 19:16

  I'm very interested in this, what's the current state? I have a similar issue, which is a folder of scans that I would like to "publish" so it can be seen by the multi-loader.