RV/Shotgun Publishing feature

RV
,
1

Hi RV folks,

I’ve reviewed several different approaches to Publishing to Shotgun and to me, RV seems like it’s the best approach for QC’ing imagery and when using Deadline after the image sequence has completed rendering via Deadline submission.

If an Artist launches RV to review or QC their work/imagery they would hypothetically have the option to go to the RV/Shotgun pulldown menu and select Publish if that option existed. I wouldn’t want to auto Publish every render that’s submitted to Deadline unseen. From an Artist perspective I’d rather it’d be used as a QC tool and if everything looks good, they Publish.

Would be good to know if anyone has written something like this for RV and sharing, as I loath recreating the wheel.

I guess the other option is to use the Standalone Publisher but why not do it in the same package after QC’ing?

Thanks all!

Best,

Dan

2 Likes
2

Hi @walkerdan1,

Welcome, and thanks for your question! Yes, RV has a submission tool built-in with the Shotgun integration. You should see it under the Shotgun menu in RV:

image

Once launched, the artist can select from their list of Tasks, then enter a quick description for some added context for the submission.

3

Hi Brandon,

Thanks for the reply although I’m primarily looking for a Shotgun Toolkit Publishing mechanism for Artists while they’re in RV.

Example:

A Houdini Artist QC’s their work that was rendered on the farm in RV, then has the option in RV to Publish that image sequence and scene file that was associated with that render. All that data is in the Deadline render log [scene name, version, path & the output from that scene].

The Submit Tool does not perform the Shotgun Toolkit Publish.

Thanks!

Best,

Dan

4

Ah, thanks for the extra info. You’re correct, the regular submit tool will only create a Version from the media being viewed in RV. I’ll ping the Toolkit folks to see what they recommend.

5

It’s an interesting problem. I guess the main problem with this is only the reviewable media, eg renders, will get published, where-as publishing from the DCC ensures that the scene used to create the render is published at the same time.

This may or may not be an issue for you, but I take the view that it is essential to lock a scene to a render so if you ever have a client request to go back to a particular version, then you know for sure you have the exact scene that was use to generate the render. If you submit a render, and then publish from another app, eg RV, then a) you have no direct link to the sourcefile used to create the render (some kind of metadata file in the render folder could store this infor), b) even if you did have a reference to the scene used to render the scene, the artist might have edited hte scene after submitting the render if they forget to version up at that point in time. The safest option would be to make a copy of the scenefile at render-time that is used by the renderfarm to render from, and which would be the file that gets published when you publish from RV… but you would have to make sure you’ve created new templates for this temporary render workfile so it can be picked up correctly by SG in the publisher.

This only covers simple situations. What happens if you’ve submitted a render for review of lookdev, and the publish actually needs to export objects from within your scene? In that case you would still need to go back to the DCC after reviewing the file to publish the scene, Version, and shader definitions, caches, etc. It’s at this point I ask “is it worth the hassle?”…

I guess the answer depends on how simple your publishing requirements are. If you only care about image sequences, then it definitely would be worth publishing direct from RV… but for more complex publishing, you would have to tackle some interesting problems, and possibly unecessarily complicate your code-base.

I’d love to hear how other studios have tackled this question and what workflows have been most successful.

2 Likes
6

Our CG artists are dedicated to one aspect of a shot so whatever they version, is their version and it’s not handed off to another artist for completion.

Any imagery created that’s handed off to a Compositor from another department is versioned, so at this point, there’s sharing happening from the CG artist to the Compositors.

If a Houdini Artist renders something on the farm, there’s the Deadline render log that contains [scene name, scene version, scene path & the all the info from the output from that scene].

After the Houdini Artist QC’s their renders in RV, they could have the option to SG Publish the imagery they created along with the scene that was used.

I have a mechanism in place in my custom [SubmitHoudiniToDeadline.py] that forces the app to save the scene prior to hitting the submit to Deadline button and after the job has been successfully submitted, the Artist is prompted to version up, after the scene has been submitted for render. When the Artist chooses to version up [and they’re instructed to version up on each submission] the SGTK “File Save” feature is executed so they’re versioning up via SGTK and not through Houdini.

Technically all the information is there in the Deadline log to collect what’s necessary for a scene and image seq SGTK Publish.

“This only covers simple situations. What happens if you’ve submitted a render for review of lookdev, and the publish actually needs to export objects from within your scene? In that case you would still need to go back to the DCC after reviewing the file to publish the scene, Version, and shader definitions, caches, etc. It’s at this point I ask “is it worth the hassle?”…”

I concur somewhat on this point, but it’s a catch 22 here. You submit a lookdev render to the farm, wait however long it takes to render and at the completion of the render, do you still have your scene opened in your DCC, waiting to SGTK Publish your scene, shader definitions, caches, [what you just rendered], etc.

Would be cool if there was a SGTK “Create Manifest” of an entire scene file [kinda how the SGTK Publish collectors works] and that generates a metadata file with everything found [the manifest file could be saved by the scene file and versioned like the scene file]. If performing an external SGTK Publish like I’m wanting to do [e.g. via RV, Deadline, etc…] you wouldn’t need to have a DCC opened, because the Manifest would be parsed at Publish time and the collected Assets would be published.

Not sure how feasible this would be but in my head it sounds good. :slight_smile:

2 Likes
7

Great idea, I was thinking along similar lines.
The publisher in RV could then present all the possible publish items, and on submission, the manifest would be sent to the farm to be processed with the farm_wrapper script (in the DCC thus allowing any DCC specific processing eg abc/usd exports).
Unfortunately, something like this is probably outside the remit of SG devs given its dependence on a specific renderfarm system.

2 Likes
8

Know anyone super smart to create something like this? :slight_smile: I think the guy that wrote the Natron and Toon Boom engines would be a great candidate!