Anyone have any solid examples of doing non-render things with MayaBatch? I am thinking about making a server to batch export animations, the machine is a xeon w/ 8 cores, so I would like to use them, just open a few MayaBatch, then set their affinity.
We do this extensively. There’s no real voodoo to it. You can’t do anything that requires Maya to stick around without writing some “busy” code that sits there chewing cycles. Mayabatch exits as soon as the launch script is done. I don’t know what is would do if you have a separate python thread running that was launched from the startup script, but herein lies complexity that we’ve tried to avoid. In short, don’t try to recycle running copies of MayaBatch for use over different files, you will probably end up tracking down bugs that come from this. Treat MayaBatch like facial tissue. Use it once, then toss it.
You will need to write an external batching system as you describe, or write a MayaBatch control script for one of the off the shelf build environments tools: List of build automation software - Wikipedia
Don’t forget that you’re going to need to write some “nanny” code to monitor and nuke the MayaBatch process when one of them goes off into never-never land.
EDIT: Depending on what your build complexity is, you could also get away with using one of the renderfarm control suites such as Qube: http://pipelinefx.com/
I used to do this all the time for things like batch re-exports or refactoring existing assets without tying up my own machine. It’s a lot easier if you write your stuff The Right Way™ – that is, if your implementation is not dependent on your GUI in any way.
Nowadays I usually run things inside a maya.standalone instance - that way you can run the whole thing inside a debugger and keep an eye on your processing but have your regular GUI maya available for your own use. You can also do fun stuff like pop up an RPYC or ZMQ remote procedure terminal inside the headless maya so you can interact with it remotely or poll for job status.
Thanksfor the feedback guys. We use collada as an intermediate and compile that at build time. However, now just walking the timeline to export can take 7 mins for some special rigs, so I am evaluating exporting the anims on a server, maybe upgrading our animation batcher to use that in a distributed way as well. @Theo, none of our stuff is dependent on the UI.
Theo, do you have any examples/suggestions re: RPYC or ZMQ remote processes with standalone?
I haven’t used either of those modules before, and after checking through the docs figured I’d ask if you had any tips or suggestions for implementing them.
7 MINUTES?!
Sure… 7 minutes, we have some pretty long cut-scenes, and with face/body and possibly multiple characters, the DAG evaluation can be a chore. We limit it to only the needed joints, but still… Also, animators don’t tend to have the fastest hardware.
@capper: this thread Automating Max, Maya and possibly others from Python "interactively" - Coding - Tech-Artists.Org has some more detail
Chris, are the animators working on a stripped down rig or something? Or do they have to wait several seconds everytime they hit their timelines? Can you disable the rig or split it up to keep them working and then do the seven-minute version rarely?
Ah, gotcha. Just seeme crazy and impressive at the same time! “what in the world are they exporting?”
@Theodox, yeah, the anim versions run @45hz, but they’re not the full skeletons, they have a lot of the deformation baked into shapes. The evaluation of the skeletons is pretty heavy, and all the shapes that run on top. I would like to offload that to a server. Would still take minutes to export, but doesn’t stall them out.
[QUOTE=Theodox;20278] It’s a lot easier if you write your stuff The Right Way™ – that is, if your implementation is not dependent on your GUI in any way. [/QUOTE]
Hey Theodox,
Any pointers on writing stuff The Right Way™?
I’m a novice in Python, and, for my first challenge, I’m making a tool to export world-space baked cameras. It will be a batch job to process the latest maya scene in a bunch of shot folders.
I’ve been making reasonable (if slow) progress but, on nearing completion, I’ve ground to a halt because one of the modules I’m relying upon, from Morgan Loomis python utilities package [B]http://morganloomis.com/downloads/[/B] doesn’t seem to work in maya standalone mode.
His tools are very useful and work perfectly within a GUI maya session. However they fall over in maya.standalone, throwing the following exception:
=================================
Error occurred during execution of MEL script
Line 1.23: “$gPlayBackSlider” is an undeclared variable.
gPlayBackSlider is, I think, a Mel command(?) called in the def framerange: function of ml_utilities and I suspect it’s failing in batch mode because maya standalone doesn’t create the timeline in the same way that it does in the GUI.
I think I’ll have to write a new function “The Right Way” but I’m not sure how.
Surely the frame range information must be included in my scene files but how to access it? First and last keyframes isn’t a reliable option because, often there are keys lying outside the shot frame range ( in TVC land at least).
Any suggestions would be welcome.
Thanks in advance
NigelHaslam
Byron Bay
Australia
The Right Way ™ is pretty simple, really : just avoid making dependencies on GUI components like windows or controls. It’s slightly more complex if you’re borrowing mel because there many useful mel scripts that get defined in menu loads, so if you don’t load the gui they don’t get sourced. Most of the time you can find them by looking at the menu files in your scripts/startup or scripts/other directories and manually source them, but if they are defined in the body of the menu command you’ll have to reimplement them. Often it’s easy to work around just by looking at the underlying code and stealing the bits that do the actual work.
This one you reported is a classic example of The Wrong Way© since it seems like he’s querying the slider control to get the time range in the scene. You should be able to get the same info without the gui using the playbackOptions command. If you don’t have time to replace the whole package, you can probably replace the guts of the function with a call to playbackOptions -q (or in python, cmds.playbackOptions(q=True, min = true) for the playback slider start, etc.
As a backup, you may be able to actually instantiate a playbackslider object and stick it into a global variable $gPlaybackSlider - some bits of GUI don’t complain if you create them in a headless environment, but most are unhappy.
You can probably find other problem spots in your mel package by searching for ‘$g’ in the codebase. That’s the mel convention for global variables, so when people do write stuff that depends on the gui you’ll typically see code like ‘string $mainwin = $gMainWindow’ where people are grabbing one of the main gui components.
Hey Theodox,
I’ll search these modules for any other references to MEL, or GUI components and also give cmds.playbackOptions a whirl in query mode as you suggest.
Thanks for the tips.
NH