Render Farming

Rendering in Blender can take a long time, depending on resolution and complexity. With the rise in popularity of homebrewed and small studio 3d art, there are countless Internet-based render services available, and depending on your requirements, that might make sense for you. As always, it makes sense to support services that support open source, and one of the best supporters of open source rendering is Render Street, with Blender Cycles, LuxRender, and Yafaray services available. They are sponsors of Blender, and also help fund various open movie projects.

Render Street operates on a sliding scale, so pricing is relative to your needs.

There is an entirely no-cost option at https://www.sheepit-renderfarm.com/, although in order to “pay” for your renders, you must also contribute computer time to other people's renders.

You do not have to submit your renders to the Internet just to speed up your export. Building your own render farm is easy as long as you have a few computers to spare.

Afanasy is part of the CGRU Cg Toolkit, and it includes software to drive the render farm, to manage the render queue, scripts to produce dailies, and more.

Set up is fairly simple; install the server on a “master” machine, and install and activate the Blender plugin (so that jobs can be submitted) on the client machines.

One installed, jobs are submitted through the Render panel in Blender.

Currently there are no SlackBuild packages for Afanasy, so you will have to build and install from the project website.

If any kind of render management system is overkill, you can create an ad-hoc render farm in Blender itself. This is the duct-tape version of a render farm, but if you just need two or three computers working on a render to speed things along a bit, this could be a good solution for you.

In order for there to be multiple machines working on the same render, you must render to an image sequence rather than to a movie file. The reason for this is simple: each computer (node) will take one image to render.

Before you render, go to the Properties panel and click the Render tab. In the Output section:

• Overwrite: Turn this off so that no node in your ad hoc farm overwrites the work of another.
• Placeholder: Turn on so that each node create an image file immediately upon claiming the frame to render. This prevents two nodes from working on the same frame.
• File Format: Render to image files, not to movie files.

With these options activated, you can point each Blender instance on each computer to the same network filesystem, (you can use fish or samba in KDE) and open the scene you need to render. Each computer will render frames until there are no frames left to render.

You can run Blender in the background:

$ blender /path/to/networked/file.blend \
--render-output //relative/path/to/output/dir \
--background --render-anim -E CYCLES \
--threads 8

Which means:

• blender: invokes blender.
• /path/to/networked/file.blend: the path to the file that you want to render; store it on a networked file system so that other computers on your network can reach it.
• –render-output: this is the path to the directory where you want you output files stored. Note the special syntax of preceding the path with two slashes (//), which in blender-terms means “path relative to the .blend file being rendered”.
• –background: run in the background rather than launching the GUI interface.
• –render-anim: render the animation in the .blend file (you could also render the scene).
• –E: which render engine to use (use -E help to see a list of available engines)
• –threads: how many threads to use while rendering (0 tells blender to decide on its own).

Blender is very strict about syntax. The options themselves must come after the file paths, and you cannot combine flags (so the traditional combining of options -b -a into -ba cannot occur), nor can you omit spaces between flags and arguments (no -ECYCLES when you mean -E CYCLES).

For further details on options that you can use in the shell, run

blender --help