Dave Girard's 101 Autodesk® Maya® Tips is now available in Kindle, interactive iPad edition and DRM-free EPUB/PDF editions. Work faster, cry less. Read more about the ebook.




Follow cgbeige on Twitter

Topics by tag:



Recently published articles by Dave G:



Free downloads by Dave G:



Mac OS X-only downloads:

Mac OS X Maya (and other 3D app) users: how to set up command line rendering

I get requests to help with this a lot so I’ll post a how-to for people new to the OS X command line and UNIX. This is a quick way to get up and running with rendering from the command line and Terminal.app. 

The first question you might be asking as a Mac user is “Why would I want to use a text command when I have an interface to rendering?” The answer is pretty straightforward. A command line rendering is the most efficient way to render because:

  • Your computer doesn’t waste CPU time displaying feedback of bucket rendering.
  • It saves memory.
  • It’s a lot easier to monitor renders remotely (more on this below).
  • It frees up your application so you can continue modelling (although Mac users. can run another copy of Maya by grabbing my little launchers here.)
  • You can make batches just by adding a bunch of render commands to a text file
  • You can get render notifications with growlnotify:

But enough talk – here is what you came for. In order for Terminal.app and bash (the default UNIX command line in OS X) to see your Maya command line “Render” application, you have to tell bash where to look for applications. This means putting a $PATH variable in your bash profile. The easiest way to do this is just to open Terminal.app and paste this in text and hit enter:

echo "PATH=\$PATH:/Applications/Autodesk/maya2011/Maya.app/Contents/MacOS/" >> ~/.bash_profile

That’s one command, it’s just not wrapping nicely in Tumblr - so don’t run it as separate lines. After running that, open a new Terminal window or type “source ~/.bash_profile”) and then you can just type “render”: 

Obviously, that is only for Maya 2011 but you can just change the maya2011 to maya2010, 2009, etc. Only pick one though, or you’ll need to read on to avoid having multiple Maya Render command line applications being referenced. 

Obviously, you’ll need to learn the arguments that go with that but that’s for your own exploring, since they are different for different renderers and most offer help and examples when you type an invalid command like “render -?”, “render -r vray -?” “CINEMA\ 4D -nogui —help”, etc. 

Advanced topics or “understanding what you just did.” 

Now to break down the $PATH install command for those who think I’ve just put a Russian spy satellite in their home folder. echo is a program that just repeats what you write in quotes and » is telling bash to write the echoed text to the end of your .bash_profile text file in your home folder (that’s what ~/ is in UNIX speak). If you want to edit the contents of your .bash_profile file outside of Terminal.app, the easy way is to just type “open ~/.bash_profile” in the terminal and chances are it will pop up in TextEdit. “open” is a Mac OS X-specific command line app that acts like a double click on a file. From there, you can add more $PATH variables if you like just like editing a normal text file:

You’ll notice a few things in that list. The first is that there is no backslash before the $PATH name that’s in my echo text above. That’s because the backslash is a special escape character that tells bash to write the word “$PATH,” not spit out the existing $PATH list. If you’re editing your ~/.bash_profile text manually, leave the \ out of the text so it looks like the text in the window above. If you are interested in adding more $PATH variables to your Terminal, you need to keep a couple things in mind. Comment out programs that you don’t need or just delete them from the list. In the window above, you can see I have the Maya 2010 path referenced but there is a “##” before the line, meaning that it’s been commented out (ignored). If I had both Maya 2011 and 2010 referenced, bash wouldn’t know which one render application I wanted to use - commenting it out is pretty much the same as just deleting the line entirely - it’s just a leftover from when I needed to jump back and forth between the two. 

Check back later this week and I’ll have some extra command line render tips:

Making render batches and editing batch permissions

Ok - so you finally have your Render application appearing since you have your $PATH variable set. Now it’s time to make a batch file to put all those jobs in for rendering overnight. Let’s say we want to do two jobs - one V-Ray for Maya animation and a mental ray still image. It’s all doable in one batch file, once we have our path variables set to recognize the applications (you don’t need to have the $PATH variable by the way, it just lets you use short names for the application, instead of the full path to the application but I figured I wouldn’t confuse anyone with that earlier). So here are the contents of our plain text file “render.command” that I’ll put on the desktop (.command is an OS X extension that just lets you double click the file to open it in the terminal):

render -r vray -s 1 -e 100 -cam persp -x 1080 -y 1920 -proj /Users/beige/Documents/vrayscene/ -threads 16 /Users/beige/Documents/vrayscene/vraytorender.mb

render -r mr -s 1 -e 1 -cam persp -proj /Users/beige/Documents/mrscene/ -rt 16 /Users/beige/Documents/mrscene/mrrender.mb

Again, those are separate single line commands, with no hard returns except between the two of them.

Very important for people using TextEdit.app to make your batch files:

You must pick “Make Plain Text” in the Format menu for any of these batches to be read by Terminal/command line. The default is rich text and this will break your script because it’s a completely different encoding that the Unix shell doesn’t understand. I recommend setting all new text files Plain Text to avoid this problem entirely. Do that from the application’s preferences.

So, back to the contents of the render batch script. There are a bunch of options in the command line renders that you probably don’t need to use since Render will just use the setup within the scene file (resolution, render directory, etc). It’s important to specify the project directory (-proj) if you’re rendering different projects in a batch since Maya will just load the active one and put your images in there, regardless of where you rendered from.
If you make a render batch in TextEdit, make sure that it is plain text, not rich text or it won’t be read properly by the terminal. Next is the final and crucial step in getting a .command or shell script to be executable by Terminal.app: setting the execute permissions on the file. The easiest way to do this is to write “chmod +x ” with a space after +x and then drag the file into the Terminal window and hit enter. This alters the file permissions to make it an executable like a program. Then you can either double click the .command file or execute it in the traditional UNIX way by just dragging the file into the Terminal.app window and hitting enter to run the script:

/Users/YOURUSER/Desktop/render.command 

This is the way all shell scripts work so if you just want to experiment with creating a test script with proper permissions, instead of going whole hog for a batch, put something simple in the script like “echo test” and if the text “test” appears in the terminal window, then the permissions are fine.

Advanced technique: checking render status with the screen UNIX app

I’m relatively new to UNIX and I was a Mac guy who never touched the command line before OS X. I eventually warmed to it since all the UNIX applications built into the system can make some things easy and fast, and the screen program is the best example of this mix of convenience and speed. The need for screen stems from two problems:

  • You have a render batch you want to check on but it’s sitting in a window on your machine at home or the office. 
  • You want to create a render job on your Mac Pro or XServe from the road but when you close an ssh session, the job dies with it.

screen is the answer to these problems. It’s like a virtual terminal that hosts your terminal session and can be detached and logged into like a fake window. Thinking of this may cause a brain fart for those unfamiliar with the shell but I guarantee you’ll come back to this one day if you start doing command line renders.

Setting up ssh

First, for those completely new to ssh (the secure shell), here is a rundown of how to get up and running with a remote render. You need to enable Remote Login in the OS X System Preferences Sharing Panel. Then, if you’re using a firewall or a router, you need to open port 23 if you plan to log in from outside. Don’t worry too much about the security implications of this - ssh is encrypted and is very secure (unlike telnet). After that, you’re ready to log into your machine remotely and we can start checking on our batch renders at home or the office. If you have a dynamic IP address, I recommend getting a dyndns account so you can find your machine no matter what your IP is. It’s very convenient. So, if I made a domain pixelmolestor.dyndns.org and my user name is “policeman,” I’d log into my machine with this command from a terminal app:

ssh policeman@pixelmolestor.dyndns.org

After entering my password, I’m running a shell that is the same as running my Terminal.app window (with your $PATH variables set so Render is usable) and it’s running on my server.  

screen magic

So now the fun part (I don’t get out much, it seems). Open a Terminal.app window (you don’t need to be remotely logged in for this part) and type “screen” and hit enter. You will be shown a little warning about something - just hit space and move on. You are now running a shell session in a sort of virtualized space that can be detached without killing the contents. Let’s run our render batch command file:

$ cd ~/Desktop/

$ ./render.command 

The $ is just a standard for showing the line start, so this is two separate commands that do the same thing as just typing the full path to the script (“./” in UNIX means, current directory and “../” means one directory up). So once we see some feedback and the job is started, let’s detach the screen so that we can quit the shell without killing the render batch. Hit control-a on your keyboard - this will put screen in a command mode and then hit the “d”:

Your render batch hasn’t been killed – you’ll notice if you use iStat menus or a CPU monitor, the render’s still running full throttle. To retrieve our job, just type “screen -r” in the terminal. You’ve just resumed your screen session. If you want to kill the screen session, hit control-a and the “k” key. This will keep things tidy so you don’t have phantom screens hanging around after you close the terminal. If you want more info about screen, just type “man screen,” which sounds vaguely like a male stripper who’s a little too in-your-face. Use in conjunction with “man touch.” 

The screen payoff

Let’s say you’re using your iPhone and iSSH. I can log in and check on my job if I’ve created detached the render batch inside a screen session:

And our well-earned reward:

V-Ray on the iPhone! 

growlnotify: Lovin’ for your terminal, command line renders and Growl

This is a pretty simple way to add some Mac Growl notifications to finished command line renders. All you need to do is install the growlnotify command line app that comes in the Growl disk image. Run the install.sh script in the disk image and use your new-found .bash_profile $PATH skills to make this change: “Please add /usr/local/bin to your PATH if you have not already. Consult your shell’s documentation if you do not know how to do this.”

Then, you can add this line after command line render batches to have Growl notify you when renders are done:

growlnotify -n "Maya Render" -I /Applications/Autodesk/maya2011/Maya.app -m Maya Render Done!

or for Nuke:

growlnotify -n "Nuke Render" -I /Applications/Nuke6.0v6-32/NukeX6.0v6.app -m Nuke Render Done!


It’s pretty easy to tell what the syntax is for that so making a custom one for Cinema 4D or Octane is super easy. If you’d rather not have to worry about remembering a long command like that, just make a shell script with executable permissions and put them in a recognized path. Then you can just run the script “growlmaya” instead of the whole command:  

$ cat /usr/local/bin/growlmaya 

growlnotify -n “Maya Render” -I /Applications/Autodesk/maya2011/Maya.app -m Maya Render Done!


cat just reads out the contents of text files for you to see. So, after that, my render batch is simpler and gives me Growl feedback on completion:


12 notes | Permalink

  1. polygonspixelsandpaint posted this