Better integration with the Deadline render queue software. Specifically, Nuke and Maya render submission.
I get an error in Deadline if I try to submit to the farm with a Nuke -- Tank Write Node. Error follows...
'WriteTank': unknown command. This is most likely from a corrupt .nk file, or from a missing plug-in. Can't render from that Node.
I've tried adding the Tank engine python module to the nuke plugins path but this didn't seem to work.
Hi Mike!
Just noticed that we never replied to this publicly, even though we did discuss a bit in a private ticket - sorry!
We recently updated our Write Node docs to include better (or at last some) info on render farm integration, with an eye toward Deadline:
https://support.shotgunsoftware.com/entries/95440797
That said, we know we need to make a better push on render farm coverage and are aiming to jumpstart this over the next few weeks. In the short term, that will probably some tweaks to ensure everything we release is good to go in batch mode as well as beefing up our documentation to help people get to where they need. We feel like there is a ton of potential here and it would also be great to brainstorm on next steps once we cover the nuts and bolts a bit better.
Ryan.
We have this working with Deadline just fine, and it'll get us through the current project but I still think the render farm integration is awkward.
Atm we are setting an environment variable on all machines that are rendering nuke to look for the init file. Was wondering whether a more render farm neutral solution would be better? Something like converting the tank write node to standard nuke write node.
Or have a more focused Deadline integration with a tank plugin or event?
We've got it working but it wasn't a trivial task.
Hey!
Toke, we agree that render farm needs more (some!) coverage, and have been taking a wait and see approach on what exactly to do. Our current thinking is to try and stay a bit more neutral to start and focus on making sure all of the engines and apps are render farm "compliant" in that it's reasonable for people to use them in that scenario. We have a new release of tk-nuke-writenode coming out soon that actually implements something along the lines of what you describe, where the Toolkit write node can be converted to a standard Nuke write node for farm purposes. That should be out soon and it would be interesting to get your take on it!
Mike, would you be up for doing a call with the devs on our side to talk through what was non-trivial? We're interested to hear what the pain points are and have a discussion on what we could have/should do to make things easier and better for you guys.
Ryan.
Just saw this. Sorry for the late reply.
Previous issues:
The render farm requires a different type of startup than a user GUI session ( company specific)
Mysterious fail on open -- I found that we had to check file path arg sent into Nuke because
some input paths are invalid. The check is...
if len(sys.argv) > 0 and sys.argv[0].endswith(".nk")
This check arose from a mac user when the Nuke script didn't contain an extension.
Figuring out context and other path related activities were a problem. If this check
fails, we don't start SGTK.
Currrent show impediment:
INCITING INCIDENT -- The newer writenode is incompatible with the write node configged for older projects.
FIX(wip): I now remove/add paths to sys.path depending on which SGTK project is running.
I also kill the engine immediately before editing sys.path.
RESULT of "FIX": I get the same "WriteTank: unknown command" error mentioned above -- upon
nukescript open ( in GUI or non-GUI Nuke). However, all other SGTK apps are running correctly.
If I use SGTK File Mgr, everything works. If I open a scene cold, the SGTK Write Node fails.
Which means that the renders fail.
WORKAROUND (for now): Artists render with standard write node and publish with SGTK write node.
I'll keep plugging away until I find the answer but a little advice would be good.
DETAILS: I perform these edits to sys.path as a Nuke callback on script open.
Example sys.path before/after:
For new file, we check the project and remove any previous entries in sys.path. Then we replace with new.
Currently, I don't handle localized projects because they're still identical to out studio install,
and the core seems compatible for all projects.
BEFORE (sys.path values):
<SGTK_install>/apps/app_store/tk-multi-launchapp/v0.2.17/app_specific/nuke/startup
<SGTK_install>/apps/app_store/tk-nuke-writenode/v0.1.11
<SGTK_install>/apps/app_store/tk-nuke-writenode/v0.1.11/gizmos
<SGTK_install>/apps/app_store/tk-nuke-writenode/v0.1.11/python
<SGTK_install>/core/python
<SGTK_install>/engines/app_store/tk-nuke/v0.2.17/python
AFTER (sys.path values):
<SGTK_install>/apps/app_store/tk-multi-launchapp/v0.2.19/app_specific/nuke/startup
<SGTK_install>/apps/app_store/tk-nuke-writenode/v1.0.7
<SGTK_install>/apps/app_store/tk-nuke-writenode/v1.0.7/gizmos
<SGTK_install>/apps/app_store/tk-nuke-writenode/v1.0.7/python
<SGTK_install>/core/python
<SGTK_install>/engines/app_store/tk-nuke/v0.2.20/python
I restart the engine after resetting the paths.
Why does the SGTK Write node fail when the rest of the apps are functioning properly?
Please advise,
Mike.