I’d love to use the super advanced SMTD script provided with Deadline from within 3ds Max, however, I’ve been submitting scenes via the monitor scripts so far mainly for the reason that I often work via a VPN from home and I have to synchronize
my local drive with my studio’s centralized repository.
I’ve noticed you have a few options in the SMTD for saving the file and submitting with the job files or not saving it and submitting the network file. I’d like to build on top of that with another option that will submit the file, but replace any local
paths with my UNC network paths effectively submitting a scene sitting on my server under the same directory structure as on my local home workstation.
However, the scripts are pretty thorough, so, I’d like to ask, probably Bobo directly (I assume you did the scripts?) what concrete script fill shall I modify in order to do just that. I haven’t found anything in the local .mcr file.
There are two main components to SMTD outside of the MCR, both living in the Repository\Submission\3dsmax folder.
The one is called SubmitMaxToDeadline_Functions.ms and contains all the underlying functionality. The other is SubmitMaxToDeadline.ms and implements the actual UI.
I would rather discuss what you want it to do and implement it on my side, so everybody would benefit from the changes…
As for the feature, well, I’m afraid you will not want to add it as it is very specific and not very “safe”. Whant I need is to keep copies on the server side as well as on my local machine and I need to submit the same scene file from my local machine, with the same folder structure (I keep my projects duplicated on my local machine as well as on the server to minimize latency), except I need to re-map my local drive for the network drive so that the job files don’t contain a D:\project\shots\blabla.max but instead do contain \server\projects\project\shots\blabla.max
This way I’ll be able to submit directly from within Max using the SMTD scripts and not having to use the Monitor Submittion scripts.
The bonus feature would be the ability to choose what part of the path gets remapped to which UNC path, such as in the Repository Options (I always re-map D:\ with \servername\projectsFolder).
The current version of SMTD has 4 options for the scene file:
“Save and Submit Current Scene File with the Job to the REPOSITORY”
“Save and Submit Current Scene File to GLOBAL NETWORK PATH”
“Save and Submit Current Scene File to USER-DEFINED NETWORK PATH”
“DO NOT SAVE And Use Current Scene’s ORIGINAL NETWORK PATH”
The last one is VERY similar to what you need, except that it assumes that the file from the network location was actually loaded in Max at the time of submission. It then goes ahead and takes the maxFilePath and maxFileName of the current scene, but ignores the scene itself completely, assuming the content on the network is what should be rendered.
Your idea is VERY similar to this, except that you want to remap a portion of the maxFilePath to figure out the actual network path.
So we could add a fifth option, “DO NOT SAVE And REMAP Current Scene’s Path to Network Path”. In that case, the submitter would take the maxFilePath, apply some remapping to it (how this is specified is the only tricky question), and then include the resulting path in the job file.
If that’s all you want to do, I am ok with adding it as an option. We could make it dependent on some flag stored in the Repository, so people not in your company would not even see the option (we had code like that that was Frantic specific back in the day).
Wow, I’m surprised you’re actually considering adding this option officially. That’d be great!
As for the path, well, I assume we can’t query the Repository Option for path remapping, right?
Perhaps saving it to an INI and having it only accessible by manipulating that INI manually (I assume people using this feature would already know what they’re doing)?
*First, back up your original files
“SubmitMaxToDeadline.ms”
“SubmitMaxToDeadline_Functions.ms”
*Then, replace with the files from the ZIP file.
*Also copy the file
“SubmitMaxToDeadline_RemapLocalToNetworkPath.ms”
which is a demonstration file that remaps drive “C:” to “\GATEWAY\DeadlineRepository” which is my repository here.
*This file is a MAXScript file which defines a global function called SMTD_RemapLocalToNetworkPath.
The file will be loaded EACH TIME a remapping has to be done, so you can edit it dynamically and the UI/ Submitter will respect all changes immediately.
The function itself gets as argument the current scene path and name and returns the remapped scene file name. You can do ANYTHING inside this function to produce the actual file name that will be referenced by the Job file. No saving of the scene to disk will be performed, the network file will be used As Is.
So now you can launch 3ds Max, load a local scene, launch SMTD and select the 5th option from the list.
The text field (in read only mode) underneath it will show the remapped file name. Since my function is kind of wrong for your case, you will probably just see the original file name.
Open the repository file “SubmitMaxToDeadline_RemapLocalToNetworkPath.ms” and edit the code inside to something like
global SMTD_RemapLocalToNetworkPath
fn SMTD_RemapLocalToNetworkPath thepath =
(
substituteString thepath "D:\\" "\\\\YourServer\\"
)
and save it.
Now select the last option from the SMTD list again and the text field should show the remapped file name.
If you would submit now, the remapped file name would be included in the submission without saving the scene.
NOTE:
Several advanced options that rely on actually saving the scene file won’t work.
These include collecting and sending external references with the scene, tiling submission from the local workstation and possibly some more.
Great stuff! All seems to be working, except for one little glitch - my custop PostLoad scripts suddenly don’t seem to be re-mapping my assets.
They seem to be executing (I’m also modifying some finalRender specific settings, which worked), but they don’t repath my assets as they normally do when the job was submitted via the Monitor.
That’s just weird. I’ll have to look into this deeper, but it’s already terribly late here, so I’ll go get some sleep and try to figure it out tomorrow.
I’ve explicitly disabled the Save File option in the Render Output rollout so that my PostLoad script can take care of it, yet Deadline still overrides the output file and saves it locally to the same drive I had it set on my workstation (my D:\ drive, which should be remapped by my PostLoad script to the UNC path).
This is probably a bug of mine.
When the Job and Submit Info files are written, the current output path is written there to expose it in the [ 3ds Max ] tab.
I should call the remap function on that path too.
In short, Deadline does not use what is in the Render dialog of Max, but what is in the Job file, which is then applied by the customize.ms file.
If customize.ms runs after the PostLoad script (quite possibly it does), the path would persist…
I got it to work, but the question is - do you want to call the same function as for the MAX file, or do you want a separate remapping function for render output?
I am applying it to all relevant files including the rendOutputFilename in the Render dialog, the VRay native outputs, the Render Elements…
But if the output is remapped differently than the MAX scene file, I will have to add a second independent function.
Also, calling toLower() on the file name and then replacing lower case characters would be a good idea, e.g.
global SMTD_RemapLocalToNetworkPath
fn SMTD_RemapLocalToNetworkPath thePath =
(
substituteString (toLower thePath) "c:\\" "\\\\GATEWAY\\DeadlineRepository\\"
)
Otherwise it could miss a letter if it was expected as Capital but it was lower case…
As for the remapping, in my case, I save everything under one folder structure and we only have one network repository, so, one remapping function is just fine. But I can imagine having separate functions might be more useful to other users than me.
By the wan, what exactly are you remapping? I’m asking because for example finalRender doesn’t expose certain patsh of its own to the Asset Tracker (such as GI caches, shadow maps etc…), that’s where my remapping PostLoad script comes in and re-maps all this specific stuff to my pipeline.
I am remapping all paths that end up in the JOB file - the render output filename is the one that actually affects rendering. Also in the case of VRay, we export the VRay native saving path (e.g. for tiled EXRs saving) to the JOB file. Then we include all paths including Render Elements for Monitor navigation - I rename those.
This might be a problem though if SMTD is set to rename the Render Elements automatically, since the actual rendered scene would NOT have these RE path modifications, so the Monitor navigation paths might be off. Will deal with this later by disabling the RE repathing when your Remap Scene Path option is selected.
For now, the attached version will rename the Render Output Filename using the same function as the MAX file name.
Give it a try and see if it works. SMTD_RemapPath_20120105.zip (96.9 KB)
That was a bug.
In line 848 of SubmitMaxToDeadline.ms, I was missing the 5th mode, so it was reverting to 1st:
It should be
local theIndex = findItem #(#reposave, #globalnetworksave, #networksave, #networkuse, #networkremap) SMTDSettings.SubmitSceneMode
For this to work, the file “SubmitMaxToDeadline_StickySettings.ini” should contain
[UserOptions]
SubmitSceneMode=true
If the above is set to false or not set at all, the value in “SubmitMaxToDeadline_Defaults.ini” defines the default value for the whole company, for example
[UserOptions]
SubmitSceneMode=globalnetworksave
Valid names are the 5 names from the above list, without the # prefix. So you might want to set it to
Would it be possible to include the frame range spinners or the text-box in the SMTD GUI? So we have all the controls in one place, instead of having to fiddle around with the Render Setup dialog if we just need to submit a job and override its frame range.
If it has greater implications and issues, then don’t worry about it. It’s just that I’m so used to the Monitor Submission scripts.
That’d be great!
