Im looking for a way to synchronize the max file being rendered to the slave’s local drive, and then be able to preprocess it before it gets loaded via deadline.
I tried turning on the synchronize all aux files, but in the log it still seems to be loading the file off the network:
0: INFO: Connected to 3dsmax plugin version Lightning 6.0.0.51561 May 31 2013 09:08:20 R
0: INFO: Scene file to render: “\inferno2\projects\common\pipeline\submission_queue\2013_08_13\xyz_v0046.max”
Also, if there IS a way to actually get the file to synchronize, how can i set the path where it goes?
I have found how to add this to the job (i need to submit the max file and set SMTDSettings.SubmitSceneMode = #reposave), however it doesnt seem like i can:
[]set the SynchronizeAllAuxiliaryFiles to true in the max submitter. Would be nice if i could add any number of custom properties that are not supported by SMTD by default to the info files, without having to modify the functions ms file
[]change where the file ends up. It seems to be goin here: C:\Users<username>\AppData\Local\Thinkbox\Deadline6\slave<machinename>\jobsData, we have a fast/large cache drive in every machine that i would like to use for these files. Is it possible to change where these files go, instead of the deadline appdata folder?
So I totally thought I had replied to this already… I definitely typed something out! It must have just gotten lost in my sea of Chrome tabs or something.
Do you mean like, the possibility of having an .ini file in the plugin directory that just gets added to submissions for all jobs of that plugin? That actually sounds like a pretty good idea, and wouldn’t be too hard… I like it!
Not directly through Deadline, I don’t think, but you could always make a Junction Point (or symlink in Linux terms) from that folder to your faster storage at the Windows level. It might be a bit annoying to set up, though, since you’d have to do it for each machine. This might be something we want to add support for in Deadline at some point
Yeah an additional .ini would work great, or ‘SMTDSettings.AdditionalSubmitInfoSettings’ & ‘SMTDSettings.AdditionalJobInfoSettings’ array properties that just get appended to the appropriate ini files on generation, or something like that.
It would be definitely cool if we could overwrite where these temp files are being copied on the local drives from a central repository setting. Its not a huge deal to be honest, but we did have a couple hundred machines with a tiny OS partition, causing issues with this. I believe they are being reimaged, but others might be in a similar situation.
Do we not already have this with the current 2 x .job files? Is it not just a case of relatively new features just need to be added to the SMTD Functions library, which is just a case of writing a friendly note to a certain person in Vancouver to implement for us?
The way I see this working is more general purpose than that. It wouldn’t be really per-submission, it’d be global for that plugin. The way I’d see it working is having an extra .ini file just sitting in the plugin folder, containing extra submission settings (it’d be blank by default).
It’d be for a scenario when a studio wants a certain flag to be set for all their Max Jobs (say, per-frame dependencies defaulted to on). They’d just add the line “IsFrameDependent=True” to this new ini file, and that line would automatically get appended to any .job file that is submitted for max. It avoids the need to have people modify the submitters to do stuff like this (and maintaining that between upgrades), and event plugins seem a bit overkill for it.
Everyone seems to be kinda thinking of different things, but I think what I’ve described would be useful just based on the number of requests we get for “How do I default this to ‘on’ for all Max/Maya/Nuke submissions?”
OK, this sounds useful. However, my concern is complexity and fragmentation of the plugin architecture. I wonder if there is a simpler way to introduce the same functionality.
Thinking cap has been applied…
Jon and I discussed this as well, and it probably makes sense to leave this up to event plugins. I think we just need to provide more example scripts showing what event plugins can do. I think currently, we just have the Qt example.
