this is just a general question to collect some information prior to pursuing a more in-depth R&D, but I was thinking of creating a Deadline plugin that’d allow me to submit 3ds Max (or any other) scene files and have them process a collection of pre-selected script files.
Say, I have 25 scene files that are all OK, but need a modified camera (applied overscan etc…), for example. So, the easiest way would be, for me, to have a maxscript apply the same modification to all the scenes one by one, but, would it be possible to write a submission plugin that’d have, say, two ListBoxes or ListViews, one for the bunch of scene files that the user would add in and one for the script files that the user would specify as well. Then you’d submit the job and Deadline would fire up all the scene files in the list and have them process the script files one by one in the order they were selected in the submitter.
I’m not sure about two things:
Is Deadline even capable of managing such user interfaces with listviews and the possibility of selecting and reading an entire folder structure searching for specific file types (to speed up the scene files selection if there are many)
Is, for example, 3ds Max command line capable of executing such action so that we could really save a lot of time by running multiple scene files at the same time on the farm as opposed to blocking one workstation with the whole chunk of the files?
Thanks a lot in advance for any advice or tips, cheers…
Deadline has a multi-line file browser control that you can use in your script dialog. You can use it to select multiple files, which will be displayed one per line. When you get the value of this control, it will be a single string, which is a semicolon separated list of the selected files. You can use Python’s split function to easily get an array from this value. The control also supports standard file extension filtering. Here’s some example code:
From a submission standpoint, you could create an extra text file that contains one scene file per line. The number of lines would correspond to the number of tasks in your job. This would allow you to split up your processing on multiple machines. For example, if a slave picks up task 3, it should process the scene file on line 3.
Based on 3dsmaxcmd.exe’s usage instructions, it doesn’t appear to support the ability to run a script against a scene file. It only supports pre/post render scripts, so the scene file still ends up getting rendered. However, 3dsmax.exe seems to support this. In your 3dsmax help file, under the Index tab, type in MAXScript and then click on the command-line sub-section.
Thanks a lot for the information, much appretiated.
Now as for the command line Max execution, I haven’t found anywhere whether an interactive Max license is required or not. I assume it is, which is exactly what I want to avoid.
Anyways, I’ll dig deeper to see if I can find a solution. Thanks again!
If you make a direct reference to the 3dsMax UI, then you will need an interactive license.
However, you can actually get away with quite a bit before you can get hit by this restriction…all depends on what your maxscripts are doing…
Mike
Hmm… really? So it depends on what the scripts are gonna be doing? So, you fire up a regular 3ds Max exe via deadline? Or how do you actually enter this state of Max?
So, say, modifying objects’ properties and such shouldn’t really trigger the Max UI controls or what not, I suppose?
Rule of thumb - any script operation that requires access to the UI (e.g. adding a UVW Unwrap modifier to an object AND changing the modifier settings) will require Max to be running in Workstation mode. The SMTD submitter has a checkbox to force Workstation mode (and you can pass the corresponding flag in the .job file if you are writing your own submitter).
Also, you cannot save the MAX file without being in Workstation mode. So if your script is modifying the scene and saving it back, you have to force Workstation mode on the slaves, which eats licenses. Same applies to importing objects and trying to produce a new scene out of them - we have done this in the past (exporting XSI scenes to OBJ and importing into fresh Max scenes, then saving the result), but it needs to happen in Workstation mode.
I had to do Injection of a new camera into an existing Max file (or better, into hundreds of Max files). The files were saved during the submission process so they were exactly the same files sent to Deadline months earlier, but the client changed his mind on the camera animation and the overall timing of the sequence, so we had to automatically resubmit EVERYTHING.
I decided to avoid opening the MAX file for modifications and instead pass a Post-Load script to the job that would make the modifications to the scene on the Slave on the fly just before the rendering starts, all in Slave mode. Changing render settings on the fly is easy, in fact Deadline runs a script called Customize.ms that does just that to enforce all custom settings from the 3dsMax tab in the Monitor. Changing Scene Objects is also ok, but REPLACING THEM was an issue. It looks like the Deadline Lightning plugin already had a handle of the Camera and the attempt to merge a new Camera with the same name and replace the old one failed with a crash each time. This required some out-of-the-Thinkbox thinking (also known as “Hacking”), but it worked ok at the end.
So my approach looked like this: A new camera with a different name was merged by the Post-Load script. The old camera was not replaced, but instead its .baseobject property was set to the .baseobject property of the merged camera (effectively making it an Instance clone of the merged camera), and its .transform.controller property was set to the same property of the merged new camera, thus instancing the whole PRS controller structure that controlled the animation. (It was a Free camera, otherwise I would have needed to deal with the Target object the same way). So the result was that the renderer rendered using the existing old camera which it had hold of already, but that camera was modified to behave exactly like the merged new camera by making the two instances at baseobject level and sharing a transform controller…
As part of our pipeline, we sometimes also submit the same MAX file as multiple jobs and render different Render Elements with different render settings. A Post-Load script is added to the job to modify its render elements and render settings before the rendering starts. This works great and saves a lot of time on large scenes that could take 2-3 minutes to save the MAX file…
Ah, you beat me to my reply Bobo and indeed a lot more in depth than my answer anyway!
Awesome trick on the camera. This would make an excellent blog post as people are always asking on forums how to do such trickery on a renderfarm machine.
Mike
