Anyone finding that when you use the max Batch Render via Deadline, when you submit the job(s) they are just named BATCH X OF Y, rather than being named something useful, like the Batch Render name you’ve already assigned in max? Is it possible to fix this?
Another unrelated issue is that when using Batch Render, when rendering via Backburner, even if you have Lock Viewport enabled, it will properly respect the cameras in your Batch Render list and render the correct camera for each task. In Deadline this is not the case, and it will render the same camera (that you have locked) for all of your batch tasks. If you inspect the task in Monitor it correctly lists the chosen camera for that batch task, so there’s no indication that it will render the wrong camera. I would regard this as a bug, personally, although I can see why some might not (strictly speaking it’s working as intended), although at the very least Deadline sanity checker should warn you about this I think.
Well, I wonder if the locked viewport is related to this in the FAQ:
The batch business is fairly doable. I think we’ve built a bit of a standard there, so I may need to just show you how to play around it with as a customization. How are your MaxScript skills?
Thanks for getting back to me quickly. We’re on 2016 here, so we’re not getting that error message in Deadline at all during Sanity Check. It’s effectively being ignored and overriding the Batch Render settings.
My max script skills are super basic, and we’re very new to Deadline and customising the private sanity check, so if you can help that would be great.
I see what you mean about the Batch View naming not being included in the Job Name.
To fix this, do the following:
In 3ds Max, click on the Scripting menu, select Open Script… and navigate to your \(RepositoryShare)\submission\3dsmax\Main\ folder
Select the file SubmitMaxToDeadline_Functions.ms and open it.
In the Editor, search for the string " (BATCH " - there are two places in the file that have that token.
Edit the two lines to change them from
SMTDSettings.JobName = theJobName + " (BATCH " + currentJob as string+ " of " + numberOfBatchJobs as string + ")"
to
SMTDSettings.JobName = theJobName + " [View:"+ theView.name +"] (BATCH " + currentJob as string+ " of " + numberOfBatchJobs as string + ")"
Alternatively, if you don’t want to include the base job name, you can change them to just
SMTDSettings.JobName = theView.name +" (BATCH " + currentJob as string+ " of " + numberOfBatchJobs as string + ")"
Press CTRL+S to save the edited script.
Restart the SMTD submitter (no need to restart 3ds Max).
Try batch-submitting some jobs…
The viewport lock is still an issue in all versions of 3ds Max. We applied some additional fixes in the submitter recently to unlock the view during submission and then lock it again after it if the viewport was maximized. We had to do this because in Max 2017 (and I guess 2016 and 2018) it could result in the viewport #1 being rendered if the viewport #4 was locked and maximized.
What exact version of Deadline are you running?
I will have to do some additional tests to see if a locked viewport interferes with the Batch submission - we should probably make sure the viewport is unlocked as the batch submission needs to set the viewport to a custom camera. We pass the Batch View Camera as forceCamera: argument to the submission function, so I would expect the Slave to ignore what 3ds Max has to say, and go with the Camera set in the Job file. But since the viewport locking has always been very buggy in the Max SDK, it is possible that something goes wrong at render time on the Slave…
I was able to reproduce the Viewport Lock problem with Batch submissions.
I was also able to fix it by adding a line to unlock the viewport just before the batch submission loop makes the call to submit the job.
In the SubmitMaxToDeadline_Functions.ms file mentioned in my previous post, search for the line
Thanks Bobo these are great! I will try to implement them soon and test. Great to hear they’re being rolled out into the next update of the script. I wonder if you’d consider making that job name change standard in the script too. I can’t imagine a scenario where users would prefer the current behaviour, when Batch Rendering.
Just out of interest, how do those updates work? Will we be notified or is there an update checker of some kind?
Many thanks again,
EDIT: well, they work perfectly. thanks so much again.
Of course we will include the Job Name change too. From my tests yesterday, I decided to go with the first option, where both the original job name, and the view token, are included in the Batch Job name. Having just the view would be nice in the Monitor when the Batch group name is visible, but when I went to edit Job Properties, I felt the simple “View01” wasn’t descriptive enough when seen out of context.
The reason it was incorrect is that Batch submissions have always been a red-headed step child in SMTD, and few people seem to use them. They are hidden under the Misc tab and we even tried to retire them at some point. Thanks for the feedback, I believe this is was an easy but positive change.
It is our policy NOT to force updates upon users and studios. We understand that Deadline is often the backbone of a pipeline, and any change, even if intended as a positive, could have unexpected effects in the middle of production.
The way the Deadline integration script (SMTD) works in 3ds Max is that each time you activate the Submit to Deadline menu item or UI button, a small client script that you installed when you first rolled out Deadline connects to the Repository, and copies all relevant files over to the local workstation, then loads all functions and opens the User Interface. This ensures that all machines in a studio are always submitting using the same version of the script.
When you update Deadline manually (probably between projects) by installing over an existing Repository installation, we replace the relevant function and UI scripts with the latest versions, while keeping any studio-wide INI files (like the SubmitMaxToDeadline_Defaults.ini) untouched to prevent changes to the SMTD settings. We only copy the INI files if they are missing in the folder, e.g. when a new installation in a clean folder is performed.
So if you are running, say, Deadline 9.0.5.0 and then update the Repository to 9.0.6.1, any changes to the submission script included in that new build will overwrite the previous scripts, and when you launch SMTD on a workstation, those changes will be pulled from the Repository and you will get the latest and greatest script.
If you then install Deadline 10.0.1.1 in a new folder, the installer will switch the DEADLINE_PATH environment variable to point at the Deadline 10 binaries, and opening the SMTD UI on the same workstation will automatically connect to the Deadline 10 repository, and pull the updated Deadline 10 SMTD scripts. If you decide to switch back to Deadline 9 for some reason, you can edit the DEADLINE_PATH environment variable, restart 3ds Max, and launching SMTD UI will connect to the Deadline 9 Repository, and pull the older version of the submission script! This lets you run several versions (e.g. 8, 9, 10) side by side, and whenever you switch the environment variable, your SMTD scripts will follow and pull the relevant versions of the files from the respective Repository!
