Just a heads up, I’ll post logs etc. at some point soon as I’m done with this for today:
I’ve just dropped back to 6.0 as after half a day of trying to get maya 2014 to render with 6.1 beta6, I ran out of time (and my frustration level can’t go much higher).
I suspect our maya setup is non-standard enough to the be the issue - our Maya.env simply contains a PYTHONPATH= , so our entire maya environment setup is via python. When rendering maya batch with deadline, either via our own rendering plugin, or by simply submitting via the MayaSubmission menu in Monitor, it never seems to get to the python call. Logging sys.path shows a completely different setup to what it should be too.
6.0 isn’t ideal though - we get lots of
“Error: ImportError: Module use of python26.dll conflicts with this version of Python.”. Something wrong with the python config?
at Deadline.Plugins.ScriptPlugin.RenderTasks(String taskId, Int32 startFrame, Int32 endFrame, String& outMessage, AbortLevel& abortLevel)
errors on the farm, which is what I was hoping 6.1 would deal with, but jobs do move through.
Thanks, I will check them out. Reading through one it lists setting PYTHONHOME as part of the solution and that’s certainly something I had no success with, it modified the logged output and maya could find it’s own files again which was a plus but nothing else in our setup was loading - but I’ll download the two .py files and see what I can glean from them.
No joy with any of that so far, the if I use the mayabatch that ryan posted it sets PYTHONHOME but fails to load the userSetup.py, as does my own setup when setting PYTHONHOME.
I wonder now if beta7 will be the same deal for us since others are sorting themselves out with PYTHONHOME(?), which doesn’t seem to be enough at this end.
I’ll have another go at setting the entire environment before render, I did try the other day but now suspect I was using the wrong setenv call (though I can set PYTHONHOME just fine).
I did find one slave that happily renders in 6.1 in maya2014. Our slaves are built from images and my comparisons of the systems so far don’t show anything in particular being different but I can continue to check out that side of things.
Ok. It looks like the Maya.env file is ignored under deadline - or at least our use of it, and it only contains a single line.
I ended up putting a local userSetup.py file in the users/docs/maya/(maya)/scripts location which points to the main one, with a check to make sure it hasn’t already been run as we’ll need to distribute this to workstations and running the userSetup once is slow enough without doubling up.
Distributing this now and going back to beta 6 to see how it fares.
Are you setting the environment in your MayaBatch plugin, or in the job environment variables? If it’s the latter, send us your modified script and we’ll take a look.
When setting the environment for the rendering process, there is the SetEnvironmentVariable function for the ManagedProcess/DeadlinePlugin class, and there is the SetProcessEnvironmentVariable for the DeadlinePlugin class. The former only affects the main executable that defined via the RenderExecutable/RenderArgument callbacks in the current class, while the latter affects all processes started through the Deadline plugin API. The key thing is that process-specific variables defined using SetEnvironmentVariable will take precedence over the global ones set by SetProcessEnvironmentVariable, and any variables defined in by these functions will take precendence over any job-specific environment variables.
That might be a bit confusing, so I’ll go into specifics on the MayaBatch plugin. In the MayaBatch plugin, we’re using SetProcessEnvironmentVariable to set PYTHONHOME. That means that if PYTHONHOME is defined in the job environment variables, it will currently be ignored. So if you are trying to set this variable in the job settings, that might be the problem, and we should be able to workaround this if that’s the case.
It is interesting that it works on one machine though…
I guess my starting point is that our setup is not new, and has worked in production the way it does now for years. I imagine you’re looking for a seamless deadline 6 or earlier to 6.1 upgrade path.
Maya Batch renders under deadline 6 and earlier had never had a problem calling Maya.env - Mike, I saw the link you posted to the arnold post, if this is globally true I don’t know why we have never seen a problem before as our maya.env file loading is not optional for us to be able to render. Also I’m not trying to be rude but I’m not sure why I’m looking at descriptions of maya environment variables - we have what might be described as a reasonably advanced maya loading setup which configures itself on the fly to cater for the requirements of multiple departments and also the individual requirements of specific render jobs.
I can open a cmd and run maya batch, and it loads our setup fine. When deadline 6.0 calls maya batch it loads our setup fine. Deadline 6.0 calling maya 2014 is not quite fine, there are python version errors thrown which is the main reason we need to move to 6.1 - but it’s still loading our environment fine for 2014.
When 6.1 calls batch it fails to load our setup, so I would think that the environment being passed for it isn’t actually what it should be. We are using a custom plugin.py, but it’s also true for us with the supplied mayabatch.py (the updated one that sets the python paths).
We’re rolling out 6.1 this morning to test the changes I’ve made to our setup.
I responded to you via email directly, but I just wanted to mention here that I’ve confirmed Maya.env is loaded when Maya is in batch mode, and in my tests, it loaded fine for 6.0 and 6.1.
It turns out this maya problem only surfaced if the Slave was started through the launcher. If it was started by itself, it rendered fine. We’ve tracked down the cause, and the fix will be included in beta 7.
