New post
0

Using Nuke and Shotgun without the concept of separate work and publish locations ?

Avatar
Donat Van Bellinghen
None
Follow

Hi,

In our current configuration we are using Nuke combined with Shotgun in I guess the standard way, ie Nuke projects files are stored in a work area before being published. When we publish the comp a copy is placed in the publish area. Same thing goes for images rendered from Nuke. 

 

This is perhaps an heretic question, but we are wondering if it would be possible to configure Shotgun to get rid of that 'concept'. In other words, there would be only one location for nuke setups and for nuke rendered  images. Publishing comps or rendered images would create a version in the database, but no copy operation would take place.

 

I think I understand some of the advantages of the concept of a work area versus a publish area but in our case we worked without this concept for a very long time and have had very rarely issues with it. It was extremely rare for a version to be overwritten by mistake by someone else.

The reasons why we are asking for this are : It would save disk space, save time (the copy operation), and if a few frames are to be rendered again we could overwrite the offending frames without having to render the whole sequence again.

Regards

Donat Van Bellinghen

www.nozon.com

 

 

Date Votes

6 comments

  • 0
    Avatar
    Permanently deleted user

    Hello!

    Great question and by no means heretic, at least not as far as we are concerned :)

    We know that workflows tend to differ greatly between studios and we have tried to design toolkit in a way that makes it easy for studios to embrace and be able to use their workflows rather than having to adopt some new scheme. Tweaking workflows is usually done by configuring the various toolkit app configurations - you can for example control the file system layout and decide where on disk your work and publish files should go.

    Your desired workflow goes beyond just locations - it sounds like what you are after is an actual change to the behaviour of the publishing! This is a little bit more complicated, but still perfectly possible to achieve. Toolkit is essentially a suite of different apps, each with its own functionality and features. By default, toolkit comes with its own publish app, which has a concept of a work and publish area. There is nothing stopping you from creating your own publish app that implements a workflow with a shared publish/work area. This however does require a bit of programming. We have made all our apps open source on github so you don't have to start from scratch - quite a few of our clients have taken our toolkit apps and modified them to suit their specific workflows - it requires coding but you don't need to start from scratch if you base it on something that already exists! (here is the publish app).

    Having said that, your workflow is pretty close to what we have and sounds quite interesting - I'll loop in the rest of the group and see what they think! Maybe this is something we can/should support out of the box with some minor tweaks.

    Thanks!
    manne

  • 0
    Avatar
    Permanently deleted user

    Quick update! I spoke to the rest of the dev team about this and this should be possible to configure via various hooks and settings - however having said that, it is definitely an "advanced" customization and we are not sure anyone has tried this particular setup before, so we were thinking of setting it up ourselves as an example! Both to make sure that it works (since it is a little bit special and things like file permissions handling etc may have to be specifically tweaked) - and also to help you guys with what is a bit of a complicated case! We'll get back with some more concrete info once we have put together the example!

    Thanks!
    Manne

  • 0
    Avatar
    Donat Van Bellinghen

    Thanks a lot. Can't wait to test this

     

    Regards

    Donat

  • 0
    Avatar
    John Coldrick

    *Gentle poke*

    Has anyone had a chance to look at this?  In 3D we seem to have even double the problem - we want to setup a precomp script for compositing that has all our layers, and the nodes to rebuild the beauty from those layers, and want to publish this as a script(easy), but because the rendered elements aren't shotgun write nodes, they can't even be published currently from here.  We would have to create shotgun write nodes, render them(which would simply be dumping them out again!), then publish those, then read those published nodes back into a precomp and publish that!  Whew!  Of course, we aren't doing that, so consequently we don't get any of the versioned publish loving for 3D rendered layers.  I suspect the better option would be to publish the rendered layers outside of nuke(how?), which still would require copying them, then pull those into a comp script.

     

    Not intending to fork the discussion - possibly this is something best done outside of nuke, but the copying of a lot of render layers still be would happening regardless...

     

    Have I missed something and this is doable now?  Manually dragging many render layers to the browser would be quite brutal...

     

    Thanks!

     

    J.C.

  • 0
    Avatar
    Donat Van Bellinghen

    Hi Manne,

     

    Any news regarding this ? Just wanted to say that we are still be interested in this.

     

    Regards

     

    Donat 

    nozon.com

  • 0
    Avatar
    Permanently deleted user

    Hey!

     

    For both these things, you should have a shotgun template which matches your render output, wether from Nuke or from 3D...

     

    In this way you can then publish your 3D renders from Nuke with custom scan-item/pre-publish/publish hooks. Checkout the paths_from_template function https://support.shotgunsoftware.com/entries/95441117 or roll your own file-finding function. So you can go through all the read nodes, publish the files, switch the read-nodes path to the published path. And maybe just copy the resulting nuke script over the one that got published as a primary publish.

    For not having a work area: I think if you just reuse the work-render output template as your publishing template and modify the publishing hook to not do anything to the work files (like trying to copy them over themselves), it'll register the work renders as published, using the work area path...

    Well, maybe that'll help some...

     

    Cheers,

    SebastianH

Please sign in to leave a comment.