Last time, I looked at manufacturer-specific render farm management software. While this software can make a very good solution for many people, it doesn’t tell the full story. Many CG pipelines need to render images that have been created using software from several manufacturers. In order to effectively manage such pipelines, a third-party solution is needed that can queue and dispatch jobs to several software packages.
There are several packages that are capable of this and most of them act as remote program launchers with some kind of front-end queuing system. If you are planning on building a multi-package render farm, you will need a copy of each software package you intend to render along with all plug-ins installed on each of your render nodes. Licensing for this varies between software packages, and most manufacturers offer a number of render-node licenses for free with each seat. Many render farm managers make use of the built-in network rendering functionality discussed in the last article. This helps them to get around any licensing issues and means you can avoid having to buy a fully licensed copy of your chosen software package(s) for each render node.
A few things to look for in a render farm manager are:
Queuing and priority – This should be present in any solution worth its salt – the more granular the better. On a large render farm, options to control queuing/priority on a per user basis can be very helpful. Some managers also have options for creating clusters of nodes that can then be assigned to a certain artist or department. This ensures that, on those nodes, the artist will always have priority.
Resource management – You may have a limited number of render node licenses for certain software packages or plug-ins. For example, you may have 20 render nodes but only 10 licenses for a certain plug-in. If your render manager tries to send frames using this plug-in to all 20 nodes, you may end up with certain elements not being rendered. Your chosen render manager needs to have some kind of method for managing these resources to avoid this happening.
Job dependence – Many render jobs will depend on other other elements being completed first. You may, for example, have a final scene that uses externally created textures. If you were to submit the rendering of both the final scene and the baking of the texture to your farm at the same time, it may try to start rendering the final scene before the texture is baked. You need some way of telling the manager not to start rendering the final scene before the texture is baked.
In-app submission – Most artists will prefer to submit jobs from within their applications rather than using a render manager’s GUI. If you are planning on letting artists submit their jobs directly to the render farm, rather than through a render wrangler station, then it is worth checking that your chosen solution has submission plug-ins for the software you are using.
The Future of Render Farms
Everyone seems to be talking about GPU-based computing at the moment and, with its large amount of relatively simple calculations, CG rendering could lend itself very well to technologies such as CUDA or OpenCL. There are already software packages, such as iray and StudioGPU, claiming tenfold speed increases when rendering on a GPU as opposed to the CPU. These packages are yet to be widely adopted but considering such speed increases, it is bound to filter down into the more mainstream packages as it matures. NVIDIA are already shipping Tesla GPU clusters consisting of several GPUs connected by high speed links. In the future, we may see render farms built (at least partially) out of these clusters instead of traditional CPU-based servers.
If you are planning on building a render farm and would like some advice on the options available, give me a call on 03332 409 309 or email us at firstname.lastname@example.org. Visit us on Facebook or Twitter (@Jigsaw24video)