Hello,
I’m just wrapping up some work, to more tightly integrate the deadline vray spawner deadline plugin work flow with The Mango Pipeline.
Our first task was to re-implement the maya submitter in a way that would allow us to better tie in our software profile based configuration tool. and second make the submitter code more application agnostic, so that we could reuse our development across other applications with out having to support duplicate code basis for each DCC App…
One of the places where we think the process could be improved is in how the deadline plugins derives where it will look for the vray spawner and stand alone executable as more professional studios most often boot strap this binaries from version folders in a network location, and have the need to manage multiple version currently (usually manged thought deadline preJob.py).
In short the current option to add the path to the vray spawner via the plugin configuration screen works great when vray is installed manually on the local machine, but if distributed procedural via the maya _module_path environment variable from a network location folder such as vray_34003 the system becomes much harder to manage and keep operating in good health.
Ideally having the option of submitting the location to the vray.exe via the job properties to overwrite the plugin configuration would be a welcome addition.
In the mean time our work around is to have the vray spawner plugin configured to look for it’s binaries in a folder C:\mangoVRayDistSync%dccApp%\bin and have our profile based configuration tool, sync the v-ray binarias to match the artists vray version…
While this work around those in deed work at the moment, it has unnecessary over head on startup, and has an unneeded added point of failure.
Is there a parameter in the submission options i can use to overwrite the .exe search path already?
If not would it be possible to request such addition?
Thanks very much for the feedback. Typically, studios in this situation will create a “wrapper” script which resolves file pathing dependencies, perhaps via env vars or otherwise, to resolve to the exe path for a Deadline plugin. So, in this case, you would create a wrapper script, which queries something either globally or locally configured via a SCM system such as “maya _module_path” env var which then constructs the exe path, given any parameters you wish to use to control the pipeline. This wrapper script is typically stored server-side and is the file path that you enter in the Deadline “Configure Plugins…” section for each app plugin exe. Some studios, even create an alias here, to further handle different sites (offices), etc.
Additionally, if you need to FULLY bootstrap your pipeline for ALL plugins, then we have a new intercept API hook (ModifyCommandLine API hook) coming in the next version of Deadline which will allow this. Reading your notes, this isn’t required here, but I mention it in passing.
The above would allow you to dynamically “swap” out different versions of software depending on a parameter of your choosing, say, an extra JobExtraInfo variable in each of your submitted jobs.
yeah very cool…
so what you’re saying is do a wrapper for the vray.exe that can basically choose the correct location?
I think this is pretty double, as it would basically just pass the arguments to the “real” exe?
could it be a simple as a .bat file?
I did try this before but it was for the 3dsmax plugin which actually checks the .exe for some version data, so the wrapper approach doesn’t work in that case…
the wrapper approach fixes some of my issues, but having a universal approach so that all plugins have a similar solutions would be great…
So have plugins that check the provided .exe for specific properties (like 3ds Max) maybe not do so? or giving us the ability to override the .exe list via a key value pair?
anyway thanks for listening i will look into the wrapper approach as its well within my wheel house.
cheers,
Los.
Yeah, sorry about that. This is currently a known limitation unique to 3ds Max and we have an internal dev ticket to remove this restriction in the future.