submit batch without masterJob

With smtd can I submit all the batch jobs directly from the workstation?

thanks,
Ben.

Currently, this is not possible. I think it has to do with the way the batch submitter needs to “refresh” Max when updating the current view to be submitted. I believe if this were to be done within SMTD on the workstation, it could mess things up in the current scene.

Bobo might be able to clarify though…

Cheers,

  • Ryan

The Batch Render of Max can apply various changes to the scene including States and Render Presets. While nobody seems to use States, they CAN be part of a pass so we have to either save a copy of the current scene, process the submission locally assuming that states could be applied, then reload the saved copy, or use a Master job. This would be slow since the scene would be saved once in the beginning, once for each batch submission and loaded once. Currently this is offset to the Master job.

We could also check to see whether there are Render Presets and States in the current Batch setup and if there aren’t any, allow to perform the submission without a Master job. Or do what I described above with the temp. file saving.

A third option that I would probably prefer would be to submit the current scene to the slaves as is and pass the relevant State name and Render Preset file with the job to be applied post-load/pre-render. This way, the scene has to be saved locally just once like for a regular job, then the Camera, Resolution, Render Pass, State and Output Path info could be added to the Job Info file and applied at render time. A drawback of this method is that the MAX file on the slave is not exactly what will render if you decide to open it from the Repository for tweaking - it would depend on external files to turn into its final form…

I am inclined to try the last approach…

The current issue is if it needs a workstation license, I apply the “workstation” limit group. But then the child jobs also have the “workstation” limit group applied. So the master job ends up sitting in the queue way too long before it spawns.

I only ended up using batch when rpm gets too fragile so I never noticed this until now.

B.

I might be getting confused, but didn’t the SMTD some versions ago, have the ability to submit batch-render jobs with hence, different scene states as separate jobs? It was an option under the batch render drop-down list, but got removed for a reason I forget?
Mike

so annoying…waiting forever on a master job. and its stuck on the unit question dialogue box!

thumbs down

B.

strange as deadline normally handles this dialog box everytime in slave and workstation mode…
It should autmoatically click on the “inherit file units” and also click OK.
line 1549 in the 3dsmax.py plugin file should read:

# For File Units Mismatch dialog self.AddPopupHandler( ".*File Load: Units Mismatch.*", "Adopt the File's Unit Scale?;OK" )

Mike

We had options for the TILES because in the case of Tiles, all that changes is the region and the image name, and these can be sent with the JOB INFO file without resaving the scene. So we made the local submission of tile jobs the default mode.

For Batch rendering though, we have to load Scene States and Render Presets to support everything the Batch dialog allows.
We could change output path, camera to render and resolution to render to using the JOB INFO file without resaving the Max scene, so if nobody of you is using the Scene States and Render Presets options of the Batch dialog, we could allow a local batch submission that just does not apply those and runs locally. Otherwise we would have to jump through some hoops as described previously.

Ah Yes, Tile Rendering, I remember now :slight_smile:
With regard, batch rendering submission, I really like Bobo’s suggested ‘third option’…it sounds very effective!
Although the 3dsMax file submitted would not be exactly identical to the actual one rendered, it wouldn’t be that hard for a studio to build an additional interface that allowed artists to import back in the settings from the post-load/pre-render script which would be housed in the repository job folder to make a ‘pulled-back deadline max file’ match identically the settings it was submitted with. Also with the stats database turned ON as well, a studio could write some py to allow it to be cross-referenced using deadlinecommand for searching purposes or at least flagged as a batch job and therefore what 3dsMax scene you’re looking at isn’t necessarily what rendered. The more I think about Bobo’s suggested third option, the more I like it!
As a side point, when studios need to submit quite a few render passes, don’t most people use RPManager these days if they work in 3dsMax?
Mike