AWS Thinkbox Discussion Forums

Job-Specific Path Mapping Rules submitable?

Hello,
I just found out that there are job specific Path Mapping Rules. My question is, is it possible to submit these with a job using deadlinecommand?
I’ve checked the “Manual Job Submission” Article in the Deadline 10.0.20.2 documentation, but it seems not to be documented. Could you make it available?

Thank you
-Robert

1 Like

Hmm. I can’t reverse the info in my usual ways (going to the ‘submission params’ page). I’ll have to raise the developers who implemented this one.

It’s Canadian Thanksgiving here today, so it may take a day or two. :slight_smile:

Hello Edwin,
thanks for your reply. It’s not a super urgent issue so waiting a few more days is fine,
I’m just evaluating my options regarding the other Issue with V-Ray Standalone.

Thank you
-Robert

Okay, so an update on our side here: The paths are built up at submission time from the “Submission Time Rules”.

I don’t have much info on your use case other than the discussion over on the other thread. I’d like to gather some info on whether or not per-job path mapping is needed and how it would work before I open an official developer ticket to ask about it.

Hey Thank you for answering.

So I’m going to describe a bit better what I’m trying to achieve:

I’m getting files from artists that are all working in their own network/server/workstation environments. Furthermore, I’m getting 3d-files, in order for me to render those scenes from said artists. Now since the artists all have their own environments there is no unified locations and naming. One artist would have a drive called X:\ the other one H:\Projects\BigElefant, one other would map directly to UNC Paths like //my-Server/g/…

So overall this is pretty messy to deal with, I cannot force them all to change their workflows and infrastructure to a specific one. My goal is that instead of them giving me something like 3ds max or maya files in order for me to render these scenes with vray, they could just give me .vrscene files with all neccessary assets collected, all paths stripped so I don’t have to deal with re-pathing all those scenes manually.

Now I’ve written scripts for the artists which automate the .vrscene export (with paths stripped) so they don’t have to deal with the the details. Further the scripts also generate the job info and plugin info files for deadline, this way I can easily batch submissions. I want to be able to submit these .vrscene files as a vray-standalone job with the necessary assets as auxiliary files (lots of textures and proxy meshes, alembics etc.). The goal is that the assets will be copied with the job to the rendernode and the .vrscene file can “see” those assets (other thread) and will render without errors. I do need to be able to wrangle output paths using path remapping though because the outputs are defined with windows paths and need to be changed to Linux locations while rendering.

I would prefer the way like I just described because it feels like the most practical one.
Alternatively I’d need a way to submit job-specific path remapping in the “jobinfo.txt” for the deadlinecommand submission. This way I could make a path remapping “rule” for every one of these artists I’m getting the files from. I could just define those remapping rules for the specific job and the specific artist with the .vrscene exporter script and submit the rules with the job. It is definitely not as sleek as the other solution but It’s definitely possible.

Do you have any alternative ideas?

btw. Just doing these path remapping rules globally will not work because I’ve already checked and I’ve quickly gotten to the point where some path mappings would “interfere” with path mappings of others like:

rule 1
win: \houseA
linux: /houseA-new/

rule 2:
win: X:\myprojects\housebuildingproject\houseA\ <-- Would not exist like that anymore because of rule 1
linux: /mnt/x/myprojects/housebuildingproject/houseA/

again, the path remapping solution would be not at all be as good as the sleek solution using auxiliary files.

Thank you
-Robert

Well, after considering the angles the best bet is going to be to customize the “[repo]/plugins/VRay” folder (just copy it over to “[repo]/custom/plugins” to get started).

I think because we’re not doing anything special with the vrscene files once they’re remapped, you can get away without the temporary folder and just dump uniquely named vrscene files into the same folder as your assets. The code that handles building the location of the temporary vrscene files this looks like this:

            tempSceneDirectory = self.CreateTempDirectory( "thread" + str( self.GetThreadNumber() ) )
            tempSceneFileName = Path.GetFileName( sceneFilename )
            self.tempSceneFilename = os.path.join( tempSceneDirectory, tempSceneFileName )

I’d forgotten before, but the only reason we have these temporary folders is concurrent tasks, with multiple Slaves, each get their own working directory so there should be no conflicts. The temporary folders also get cleaned up after the Slave is done its current job.

I think that if you skipped creating the folder and just fed a random file path and the output of “self.GetJobsDataDirectory” in place of CreateTempDirectory() this may all just work.

Thanks for the reply,
this definitely helps a lot, I’ll go ahead and try this, it seems fairly doable.

Thank you!
-Robert

Hello Edwin,
just FYI, for now I’ve solved the whole issue in a way that sill allows me to use concurrent tasks and path remapping.

I have found out that self.GetAuxiliaryFilenames() actually returns the list of the locally (already copied) Aux files. So, I’ve decided to go with the bit of copying overhead and used shutil.copy2() to copy the local files to the temp directories. It’s certainly not pretty because of the overhead but at least the network is a bit relieved.

Thanks again for your competent and quick help in this issue, it’s much appreciated.
-Robert

1 Like

No worries! I don’t get enough workflow problems to be honest. :slight_smile:

Privacy | Site terms | Cookie preferences