AWS Thinkbox Discussion Forums

Submitter Defaults

Hi,

We’ve just upgraded to Deadline 9 and are having the usual issue with artists not remembering the submitter defaults. Is there a way to set this for submitters other than the 3DS Max one? Or am I just missing something obvious? It would be useful to be able to apply a global default.

Thanks

Nick

I’d love for there to be a central preferences as well. I had brought this up before but was told the only way to do this was to program it via Python. I know that it would be a bit of an undertaking because Thinkbox would have to account for all the various submitters for all the various apps, however some other render manager software has thought of ways to do this, so it would be awesome if something similar could be created for Deadline.

We run in a school environment and we need defaults even more for students so they don’t submit with settings that actually cause the farm not to function.

It’s always been in 3DS Max (there’s so many options it would be brutal not to be able to set them) but as we’ve pushed out to other programs more over the last few years it’s frustrating not to be able to do the same in them. Plus our artists might as well be students…

Nick

Well… There’s kind of a hacky way to do it.

Sticky settings are used in most of our submitters, and they’re stored in the following locations:

Windows: C:\Users[name]\AppData\Local\Thinkbox\Deadline8\settings
Mac: /Users/[name]/Library/Application Support/Thinkbox/Deadline8/settings
Linux: /home/[name]/Thinkbox/Deadline8/settings

Mine has the following files:

AfterEffectsSettings.ini
BlenderSettings.ini
Cinema4DSettings.ini
CommandLineSettings.ini
CommandScriptSettings.ini
DraftSettings.ini
FFmpegSettings.ini
MayaSettings.ini
MediaEncoderSettings.ini
PythonSettings.ini
QuicktimeSettings.ini
SketchUpSettings.ini
TileSettings.ini
VraySettings.ini
VraySpawnerSettings.ini
ae_submission.ini
c4d_py_submission.ini
houdini_py_submission.ini
nuke_py_submission.ini

The hacky way to set up defaults would be to copy these around. They do change across versions, so your mileage may vary, but it could be a quick way to build up some defaults and deploy them to users.

Hi Edwin,

It’s good to know where these are, I’ll see if I can edit mine so it does what I want. Any chance this is on the roadmap to be setup like Max with a defaults and sticky file in the repository for each plugin…?

I’ve been using Maya and don’t seem to be getting a corresponding ini file? I’m assuming it creates one as soon as you close the submission window?

explorer_2017-05-02_16-42-50.png

So, I’d completely forgotten here. Some submitters actually store the sticky settings in the scene file (Maya, Nuke) and the settings folder is the failover when the app doesn’t let us use the scene file (Monitor submitter for Maya is a good example).

After that realization hit me in the face, I did some digging. For Maya, you’ll find out properties in the defaultRenderGlobals and so you could bake it into the default scene file:

	AddStringAttribute( "deadlineJobName" );
	setAttr defaultRenderGlobals.deadlineJobName -type "string" `textFieldGrp -q -text frw_JobName`;
	
	AddStringAttribute( "deadlineJobComment" );
	setAttr defaultRenderGlobals.deadlineJobComment -type "string" `textFieldGrp -q -text frw_JobComment`;
	
	AddStringAttribute( "deadlineDepartment" );
	setAttr defaultRenderGlobals.deadlineDepartment -type "string" `textFieldGrp -q -text frw_Department`;
	...

For Nuke, it seems to use the regular INI files.

All in all, this seems to require some digging into each submitter. I don’t have a good mental list of which submitter stores things where, so having it a standard is going to take some work. I’ll float the idea past the integration team.

Hi Edwin,

Thanks for the response, that all sounds a bit fiddly! If it was a possibility to have a setup more like the Max submitter with the stickysettings.ini and defaults.ini in the repository that sets an initial default and then you stored the individual prefs locally that would be a much cleaner option in my opinion. Obviously I understand that’s probably a lot of work but I don’t think I’d be the only one to find it useful!

Thanks

Nick

Makes sense to me. I’ll keep an eye on our discussion topic on the subject. I’ve linked this topic over there, so if I see anything on either side, I’ll keep you updated.

Right now we’ve got some ideas, and it may be a good project for an internship. We’ll have to see what develops!

That sounds good and I look forward to seeing how this develops. As an extra it would be useful to be able to transfer this to a new install. We always find that when we upgrade major versions this is the kind of thing that gets missed. For the first day of our recent upgrade to version 9 half our renders were submitting as the left eye off a stereo camera (this is normally disabled) and the render elements weren’t saving because there was a different checkbox ticked. It would certainly be useful if we have this kind of control to be able to transfer it over easily.

Thanks

Nick

Hi Edwin,

I had another thought on this, if you go ahead with creating settings defaults in all submitters it might also be useful to add in the ability to use wildcards in the submission fields as well. I keep coming back the the SMTD script, but in there you can use the nameformats.ini file to create scripted defaults (solely for the job name). We find this very useful to prefix project numbers and shot codes to each submission. Being able to use these globally would allow me to standardise the naming and generally tidy up submissions. Or being able to link to a wildcard entry to a python snippet for any field in the submitter would mean we could pre-populate information such as shot code, project etc into extra info fields as well as the job name quite easily. Just a thought… :slight_smile:

Nick

I’ll definitely have to reference this when we start working on this system. Luckily it’s referenced in the issue.

Hi Edwin,

We’ve got another feature we’d love on the Houdini and Maya submitters. We like using the ‘Out of order’ rendering in Max for preemptively debugging render times. Would love to see this in the other submitters rather than having to change it after the job has been submitted.

Thanks

Nick

Me too. One thought was to have it as another frame modifier like “1-100x5”. If you want to see something weird, there’s a secret and buggy version of that.

If you enter something like “1-100i3” it’ll give you this as a frame list:

1,100,65,33,97,17,49,81,9,25,41,57,73,89,2-8,10-16,18-24,26-32,34-40,42-48,50-56,58-64,66-72,74-80,82-88,90-96,98-99

It needs some work to be useful, but it’s a fun little easter egg.

Privacy | Site terms | Cookie preferences