The last couple of builds of deadline7 erroneously rename our render outputs.
Our render output filenames are prepared by our pipeline to something like this:
Note the … at the end, which is the standard way of forcing a ‘.’ before the framenumbers. In deadline7 release version, this gets wrangled to a name like:
TST_000_0000_d7Test_beauty_v0009…####.exr
Resulting in 3 dots.
This code seems to have changed recently, as in build .47 (RC2), it was still ok (in SubmitMaxToDeadline_Functions.ms):
format "OutputFilename%=%\n" outputFilenameIndex (filenameOnly + paddingString + (getFilenameType theRenderOutput)) to:submitInfoFile
Hi Laszlo,
Quite a few changes were made (hopefully for the better) to the SMTD code in the last few RC releases as various last minute bugs were reported by other clients. A new setting was introduced to try and solve quite a few of these reported bugs in one go, by essentially delivering to customers a naming convention variable:
SMTDSettings.Delimiter = "."
You could change this setting in the Functions.ms file to a different character or simply be BLANK to remove it:
SMTDSettings.Delimiter = ""
So, it sounds like what we have introduced is what you guys have already in place, so it’s just a case of whether you prefer to control the pipeline naming convention at your end, or prefer to let SMTD pick up this task. By setting it to: “”, you can remove it. I spent quite a bit of time, making sure the delimiter works in all the different types of tile/region/jigsaw still/animation rendering modes with/without Draft (DTA). Hopefully, I got all the different workflows correct, but I wouldn’t be surprised if I missed a particular config.
(NOTE: we have kept the tile/region naming convention of using “_” in place, so there is no change here, so any pipeline hanging off our tile/region/jigsaw implementations should remain un-affected).
Thanks, i started manually rolling back those changes, but just changing the global (or ini) setting is a much better way of doing it, ill give that a go!
Ill have to do some more digging on what changed in the code exactly. There were so many changes, my svn merge lit up like a xmas tree (always a scary sight)
This is driving me nuts… fresh start of max, both the functions.ms defaults and the ini setting are set to “”, it still puts the … in the filenames. If i manually force the setting in an open max session, it starts working ok.
Seems like i accidentally edited the _functions.ms in the locally cached path, so it didn’t stick.
So to sum up, to make this work as it did previously, i had to edit both the _functions.ms and the _Defaults.ini to patch the delimiter to be “”. Just editing the defaults ini would not work for some reason.
Behavioral changes like this should probably not be done in the RC phase though
Glad to hear you at least managed to get it working as expected, but we’ll make sure we get it working properly for the next release… I’ve logged this as an issue internally. Definitely agree that making this kind of change for a 7.0 patch might not be worth the risk, though
Hi Laszlo,
I’ve been playing with this and I can’t currently reproduce here. (In my testing, I left the _Functions.ms file struct init value as: “.”)
In the “SubmitMaxToDeadline_Defaults.ini” file:
I set under the [RenderingOptions] section the following Key=Pair (either works):
Delimiter=""
or
Delimiter=
I restart SMTD (required to re-initialise the struct) and the INI entry is taken as the ‘new’ global value. In SMTD UI, I click on the “Tools” menu at the top -> “Defaults and Sticky Settings Browser…” and scroll down to the “pink” entry called: “RenderingOptions” -> “Delimiter”, where I verify that the “Final Value” is being taken from my “Global Default” value as my global defaults INI file entry of: “”. Could you check this is the behaviour you are seeing? I submitted stills, animations, tile, region, jigsaw - stills, jigsaw - animation jobs to my local queue, with and without the VFB enabled and they all appear in monitor to be displaying the correct output paths.
NOTE: VRay VFB splitChannel & save RAW/save Alpha built-in behaviour of prefixing/suffixing a “.” such as “.RGB_color” or “.Alpha.” is still respected as we didn’t want to break any known, consistent VRay naming convention.
Not sure…, but one difference between your reproduction steps and our workflow is that we don’t use the SMTD GUI, only set some variables in the settings struct and then call these two functions:
CreateSubmitInfoFile
CreateJobInfoFile
Then do the submission using the command line directly.
So you could try simply setting some render elements / beauty pass to a double dotted filename path, then calling those functions and submitting the result.
Hi Laszlo,
Thanks for the info. Essentially, I think this is going to depend on how you are initializing the SMTDSettings.
In our examples / tutorials, we assume that even when not using the SMTD UI, the user first loads the …_Functions.ms file which initializes the structs to factory defaults, and then runs the function SMTDFunctions.loadSettings().
loadSettings() will load both the local and repository settings depending on the stickiness and defaults files etc.
If your not calling that function, then all settings will be at their factory defaults and it would be up to you to set them to whatever values you prefer.
If you are calling loadSettings(), providing a global default for the Delimiter via \submission\3dsmax\Main\SubmitMaxToDeadline_Defaults.ini should be enough.
Of course, even if you are calling loadSettings(), you can always override any of the SMTDSettings values in the submission code before calling our functions to make the submission files.
We filein the _functions.ms on submission, but i don’t think we are calling loadSettings() explicitly. That would explain why the defaults aren’t properly initialized, thanks for the pointer!
I need to write a unittest before releasing this patch to production to make sure our current workflow built on “bad” defaults is not gonna break when the defaults are fixed
is it possible that there was again a change in how (VFB) paths are being treated in 7.2.0.14?
Since upgrading to this version (from 7.2.0.10) the output files of our 3ds Max jobs do contain the ‘…’ after the base name and before the VRay render element name, e.g. ‘filename…RGB_Color.0021.exr’. This is also causing dependent Draft jobs to fail. The path shown in the right-click output menu of the Monitor and the path submitted to shotgun does not contain those double dots.
Are you sure the problem is not caused by the SMTD patch I sent you?
I am working on that bug right now, and will try to figure out the Draft / … problem.
Before the patched SMTD, the VFB raw/split files were not considering stereo camera / state set prefixes.
After the patch, they do, but it is possible that I added a delimiter too many somewhere.
Let me figure it out and stay tuned…
