My only assumption with this tip is that you use Adobe After Effects CS4 (or even CS3) on a multi-processor machine, Mac or Windows. Beyond that:

• maybe you only have one main machine and often face the dilemma of wanting to render while continuing to work
• perhaps you monitor your system’s performance carefully and have noticed that your After Effects renders don’t always peg all of the processors
• possibly you own or have owned a copy or copies of Gridiron Software’s Nucleo Pro and have experienced the joy of background rendering in After Effects already. However you’re not experiencing that joy in CS4, because Gridiron has been too busy with another little project to update it.
• It could even be that you are aware that you can kick off an After Effects render in a shell (Terminal on Mac, DOS on Windows), allowing you to render without the GUI, and thus keep working. If so, if you’re like 99% of visual artists, you’re not that fond of memorizing, typing or optimizing code.

If any or all of these is true, get ready to buy Lloyd Alvarez a beer, because he offers the answer to all of these and more. Lloyd’s site is home of many useful tools, another of which may appear in this space this month, but as my first true tip of the month I wish to promote his most infinitely valuable script. And I say infinitely valuable because BG Renderer is offered free, a 100% discount off the alternatives.

BG Renderer is a script with a little GUI of its own (shown above) that is familiar and will quickly find a home among your panels (the only caveat being that all script panels – including this one – that are open when After Effects is launched and quit will cause a crash on close. It’s a crash that doesn’t lose any data, but annoying nonetheless.

But until Adobe fixes that little bug, this one is worth the bother. You simply load it into your ScriptUI Panels folder (there are instructions showing how and where) and then you can find it in the Window menu. Its controls are simple: set BG Render Priority, maximum RAM usage and RAM cache, and toggle whether or not to use multiprocessing. Each of these sets an argument to be added to the command which is sent to the shell, and that’s all BG Renderer does – send the render or renders in your queue to the shell.

It’s just like rendering in the Render Queue, with the following exceptions:

• no completion estimation (you can of course try to calculate your own the same way AE does, by averaging frame times)
• no pause feature
• no quit (although if you know shell commands you can do it; I often Control-C my way out of a shell render on the Mac)
• no visible frames (the comp viewer doesn’t update, it’s waiting for what you want to do next)

However, contrary to what you might think, moving image formats with sounds such as QuickTime are not off-limits with this method (Lloyd just recommends you open the file before killing a render if you want to save any of it).

I find I only change the Render Priority and Multiprocessing – my renders tend to be either Low priority and no multiproc, or High with multiproc to peg those processors (sometimes leaving the machine to have difficulty even with smooth iTunes playback). Although I haven’t benchmarked to quantify how much faster this latter type of render is than a Render Queue equivalent, I have consistently noticed the processors pegged much more often when rendering this way.

You may find that you hardly ever see the Render Queue anymore. Just don’t miss the opportunity to buy Lloyd that beer.