Proxy Executable...

I’ve just spent the past 3 weeks coding a new network plugins sync tool for our studio, whose job it is, surprisingly, to sync files from a network location to the local machine. The tool is to be used with 3ds Max and Fusion, but technically could be used for any application…

The problem (I haven’t tested this yet) is how to pass in parameters to the tool so that it can configure itself and sync the appropriate files to the local system. The tool is currently designed to strip out it’s required parameters and pass on the left overs to the target executable.

Because the tool has also been designed with the ability to “switch” projects (ie, it can sync the required files for project A, but then sync the required files for project B), the tool requires at least 1 parameter to tell it which project settings to use, this allows us to utilise the full spectrum of machines we have available for all concurrent projects and reduce the possibility for mismatched plugins.

Is it possible to specify “additional” command line options to be sent to the “render executable” through deadline (which would be pointing to our tool, acting as a proxy, which would then launch the actual renderer)??
Is it possible to specify a “link” as the “render executable”??

Do you have a better idea??

I have thought about using a “config” file, but this is not suitable, because we need to the flexibility to change the project settings…

Shane

One idea that comes to mind would require some custom plugin configuration (and possibly some submission script tweaks). All of our plugins in Deadline 3.0 are written in plain text python script or configuration files. You could modify the necessary plugins to pass an additional argument to the render executable. The other half of the battle is telling the plugin what the project argument is.

There are two ways I can think of at the moment:

  1. If you use naming conventions where the name of the project is in the scene filename, you could have the plugin parse the filename for the project name and pass it. This is a nice clean solution because it doesn’t require users to do anything other than ensure that their scenes are named properly.

  2. If (1) is not a viable solution, you could modify the submission scripts to add a project field that the user would have to fill in (could be a combo box to avoid typos). The submission script would add this setting to the plugin info file (that’s the second text file being submitted with the job, that contains plugin specific properties), and then the plugin could grab this value from the file and pass it as an argument.

Cheers,

  • Ryan

Okay, that sounds reasonable :stuck_out_tongue:

I’ll give it a go

Cheers
Shane