How to add a pre-command operation to the Max Jobtype

[Roy]

I have successfully created a script in Max that will create a local zip file of the open scene and bitmap references needed to render, ask the user if previously uploaded files should be added to the zip or ignored (thus reducing redundant uploading like Backburner does), and finally move that zip file to a central server. I also have a stand-alone command line Qube submission that will remotely unzip the file to a central server so the user's workstation is not tasked for unzipping.

This is for my non-central server artist that want Backburner type submissions, but with enhancements.

All that is missing is a way to add to the Max jobtype a hidden command submission that will run my unzip command and hold the render operation off until the unzipping has finished. The goal is to not show the command unzip submission as a separate Qube job submission, but rather an integrated subjob that runs and completes before any of the workers mount the scene to render.

Thoughts?

Roy.

[Scot Brew]

Hi Roy,

It is great to hear that you are very close to replicating the Backburner file transmission functionality for your remote artists.  We'll get in touch with you to see what we can do to get you what you need from Qube's standpoint.

Regards,
Scot

[shinya]

Hi Roy,

I think the most straightforward way to implement it would be to
customize the 3dsmax jobtype's frontend script, AND use it in
combination with a cmdline job that unzips the file on the farm.

Basically, when the user clicks the "submit" button, the front-end
should submit 2 jobs-- one is a "cmdline" job that unzips the archive,
and the other is a regular "3dsmax" job, that stays "blocked" until
the unzipping job completes.

You'd need to modify the front-end submit.ms script to call your
resource-collection and zipping routine, and then submit a separate
cmdline type job that will do the unzip operation when run on the farm.
The front-end script should still also submit a 3dsmax job, as it does
normally, but put a dependency on it.  More specifically, the 3dsmax job
should be submitted as "blocked", but have an associated callback
that unblocks itself when the unzip job is complete.

I guess you could also implement it in a single job if you modify both
the front-end and the back-end to the 3dsmax jobtype, but that'll
be more work, I think.