AWS Thinkbox Discussion Forums

Deadline temp files and caching of Maya jobs

I’d like to get a couple of things about the way Deadline works confirmed, if possible:

  1. When launching a Maya job with the submission script, Deadline saves out a temp version of the Maya scene. It will continue to open and read this scene for rendering, regardless of any changes saved to the original source Maya file? This seems to have been my experience but I’d like to confirm.

  2. With the Use MayaBatch Plugin enabled, render nodes keep the scene file in RAM between tasks. I assume this means only as long as they are working on consecutive tasks from the same job, i.e. if another job is prioritized they will obviously then drop the current scene from RAM to open the new one. When returning to the first job, they will then reload from the temp file saved in 1)?

  3. At what point will render nodes load in exterior environment variables? We have been having problems with a color management policy XML file not loading, and it would be useful to know when and now often this will be loaded (maybe this is a Maya issue, rather than Deadline). I assume this file will be loaded at the start of every render task?

Thanks for any response!

Temp scenes:

Only if you choose to “submit scene file”. It will copy the scene over to the Repository. A save is always performed when submitting though.

If you don’t submit the file, making changes to the scene will be picked up whenever a render node opens Maya.

Keeping the scene in RAM:

To be specific, Deadline just keeps Maya open. It’s the same as if you opened the scene, moved the time slider and clicked ‘render’ yourself for every frame in the job. That means Maya itself, the plugins, everything stay in RAM.

If moving to a new scene, we close Maya. We also flush all local temporary files, including the scene that’s copied over from the “Temp Scene” operation I mentioned above.

Loading external variables:

Whenever the Launcher starts up. Because processes inherit their parent’s variables, anything set externally do Deadline sticks around from when the Launcher starts. The whole hierarchy looks like this:

Launcher (starts on Login) -> Slave -> Sandbox -> Maya

If you’re making changes to the environment completely externally do Deadline, make sure you close the Slave and Launcher before testing your changes. I usually tell people to reboot since that’s easier to follow, but really you need to make sure that whole hierarchy has stopped.

Thanks for the response.

“To be specific, Deadline just keeps Maya open.”

I guess I’m confused by this. I’ve always been under the impression that a batch render is fundamentally different to running the Maya application. They are even launched from different executables (maya.exe for the program, render.exe for rendering). To be clear as well, we are using the Vray plugin for Maya.

So I’m not really sure what you mean by this.

“If moving to a new scene, we close Maya. We also flush all local temporary files, including the scene that’s copied over from the “Temp Scene” operation I mentioned above.”

Also confused by this, since you say that if a job is launched with “Submit scene file” checked, Deadline saves a temp file. If it’s flushed when moving to a new scene, how is it re-created, since a job that is temporarily dormant within Deadline is not resubmitted by the user? It’s simply picked back up again when it has priority. So where does it pick the scene file up from. Does it go back to the source scene and then save out another temp?

Funny thing about this, Render.exe secretly creates some melscript and calls MayaBatch.exe under the hood. In fact, this is how we learned to implement it in the first place if Ryan remembers correctly when he told me that story years ago. In fact, you should see this in your non-batch render jobs:

0: STDOUT: Starting "C:\Program Files\Autodesk\Maya2015\bin\mayabatch.exe"

It’s exactly the same as if you close Maya and re-open it later. That is exactly what we’re doing. Because the scene file exists on disk (saved into the “jobs” folder in the repo), you don’t have to re-create it from scratch.

If you know melscript, a neat practice is to enable the “Log script contents to render log” option in the Configure Plugins section of the Monitor. At least in batch mode you will see all of the melscript that loads the scene, including path mapping, and a few other bits. As far as the cleanup of any locally copied files, you can check the “Slave data” folders:

docs.thinkboxsoftware.com/produ … vedataroot

Privacy | Site terms | Cookie preferences