AWS Thinkbox Discussion Forums

Nuke submitter

Hi,

i got a few questions/remarks about the Nuke submitter.

1.) It seems that the Deadline submission script is not creating its own tab in nuke.Root() when saving the settings for the next invocation. We have our own tab here for some pipeline settings and all the data of Deadline is added below those in the same tab. I think it’d be great if the script creates its own ‘Deadline Settings’ tab and stores all the info in there.

2.) Also, we have the suspicion that sometimes it seems to read the wrong values for e.g. the frame range as like it grabs it from the settings of a different script. That shouldn’t be possible at all, should it? Or is there some other place it stores that information as well which can then ‘travel’ across scripts? Can having more than one Nuke sessions/scripts open at the same time cause something like this? I’m sorry i can’t be any more specific as i didn’t have the chance to reliably reproduce this yet.

3.) Is there any recommended approach of how to actually fill certain fields and set knobs in the submitter panel? Due to the fact that a lot of the info already exists within our Nuke pipeline we’d like to make use of those values and keep the artists from having to do this and double-check all the settings before submitting a job - and hopefully avoid problems as described in 2.) as much as possible that way. Also, it’d be nice to be able to pass on certain side-wide configurations/policies to the Nuke submission panel. Do we need to wrap the SubmitToDeadline() function into our own and put the values there?

4.) There is a pretty nice feature in the 3ds max submitter which lets the artist choose in what mode/order to render frames (first to last, from first and last and the middle, etc.). Would it be possible to implement those modes into the Nuke submitter as well? I understand it’s probably not as easy as with 3ds max as with comps one mostly wants to render chunks of frames and not single frames per task. But i think it will definitely very useful with heavier comps that render for a longer period of time.

Cheers,
Holger

  1. I just tested here, and our submitter is creating its own Deadline tab in the Project Settings. Is that what you’re referring to? If not, can you take a screenshot of what you’re seeing?

  2. That shouldn’t be possible. We do pull from a local sticky settings file, but that’s only if there aren’t any settings already saved in the current Nuke script. If you are able to reproduce this reliably, let us know the steps and we can do some more digging.

  3. You can create a sanity check script for the Nuke submitter:
    thinkboxsoftware.com/deadlin … nity_Check

I think the Deadline 7 docs have a better example of this if you want to refer to that.

  1. We can add it to the wishlist. It might be something we could look at for 7.1 if time permits, although that list is already pretty long as it is.

Cheers,
Ryan

  1. Screenshots attached. Only now that i took them i saw that there might even be two tabs. The one called ‘User’ and the one called ‘backburnerSettings’, the latter apparently the one being from our pipeline scripts. I guess ‘User’ is the one that the Deadline submitter script creates? Not that i have checked your code but i can imagine that the script doesn’t take care of checking whether there is some other user-created tab already existing and that’s why sometimes it gets added to the wrong one as Nuke doesn’t exactly know about which tab to add it to? I also think it should be named properly, like e.g. ‘Deadline Submitter’ or so. And then i guess there needs to be a check and search for the already existing one so the data is being put there instead. Does that make sense?

  2. I guess you’re referring to those two files?

C:\Users\Administrator\AppData\Local\Thinkbox\Deadline7\settings\nuke_py_submission.ini
C:\Users\Administrator\AppData\Local\Thinkbox\Deadline7\settings\NukeShotgunSettings.ini

So is it maybe possible that when a user has more than one Nuke script open that the information gets messed up a bit? The files don’t seem to be specific to a script but generic. Just a guess…

  1. Ah, haven’t gotten into all the python possibilites yet. This looks pretty straight-forward, i’ll get into that.

  2. That’d be great. Even if not for 7.0 or 7.1 it’ll still be great even in a later release.

Cheers,
Holger

  1. Thanks! I think I might have been looking at an old Nuke comp, because when I created a new one, the settings were showing up under the User tab. This should be fixed in beta 8.

Cheers,
Ryan

  1. Looking forward to it! :wink: Do you think it will be possible to also add a proper/descriptive name to it? I think this will help also others to avoid adding knobs to the ‘wrong’ tab.

  2. I think we’re getting closer to what the issue is. The artist who stumbled upon it was able to show me the steps he’s doing. It’s basically happening when connecting to shotgun. Despite the fact of the ShotgunKVPs being filled with artist, entity, etc. it does not use that info when connecting to Shotgun but rather the information from whatever was used last - so probably the local sticky settings file. If you set up a Nuke script, connect to Shotgun to fetch the shot info, then use that to submit to Deadline and create a new version. Then do the same with a new Nuke script and and do the same but for a completely different shot, maybe even different project. Then again do it with the first script and it will then use the info from the second one to connect and select the entities instead of what was used before from within that currently active script instead.
    I think this is not how it should be.

Cheers,
Holger

  1. It will just be called “Deadline”.

  2. I think I was able to reproduce this. The problem is that we currently don’t push the settings saved in the Nuke UI to the Shotgun browser dialog, so the settings are simply pulled from the local shotgun sticky settings file that was saved the last time the Shotgun browser dialog was shown. I’ve logged this as an issue, but I don’t think we’ll be able to address this for 7.0 (it would actually affect all the submitters that support Shotgun).

Cheers,
Ryan

  1. Great!

  2. Understood. Hoping of course it will make it into 7.0 but i think i’ll be able to work around this with suggestion that you gave me for 3). So hopefully connecting to Shotgun will be necessary less often.

Thanks a lot and cheers,
Holger

Privacy | Site terms | Cookie preferences