Skip to content

Render Farms

Why Render Farms?

In some cases, rendering on your local machine is not performant or economic. For example if you are working on a complex scene and need a high resolution render or even an animation, it would take several days or even weeks to get the render of the quality you need.

Paying for compute on a render farm makes perfect sense in these cases. You will get the render quicker and in a lot of cases cheaper than if you rendered on a local machine. It does pose additional challenges in scene management.

Movie and sequence packing not supported

Blender does not support packing movies and sequences. If you want to render scenes that use movie or sequence files to a render farm, you have to send those files in a separate folder. Make sure you are using relative paths in the .blend file.

Dependency Closure

If you sent the .blend file as is your render might come back with missing textures, meshes and other problems. We need to send not just the .blend file but also all other files it depends on. This is often called a "dependency closure", we send the file and all its dependencies together.

There are two main ways to achieve this.

Video Tutorial: How to Send to Render Farm

This is the approach we recommend. You make all datablocks local, pack all external files into the blend (textures, sounds, fonts, ...). Then you send just the big .blend file to the render farm. This sidesteps problems with paths, case-sensitive filesystems and makes sending to the render farm less complicated.

Unfortunately you may need to run through several steps of making everything local. You have to make the "container" datablock local before making anything inside it local. That's why just one step of making datablocks local may still leave some linked datablocks. Check out renderset's Save Packed feature to automate this.

Packing libraries is not a silver bullet

Blender 3.0 and newer support packing libraries into the .blend but that only works for libraries with relative paths. Your mileage may wary but we recommend making datablocks local instead. It should also be slightly more efficient in cases where you don't use the entire library.

flowchart TB subgraph big_blend.blend scene --> object1 scene --> object2 object1 --> texture.png object1 --> object1_mesh object2 --> ... end

Pack to a separate file

We heavily recommend packing everything to a separate file, called e.g. scene_PACKED.blend and working on your "non-packed" .blend. It is not efficient to work on a huge file, saving and loading times will be slow and it will take a lot of space on your hard-drive.

Relative Paths and Multiple Files

We can make all file paths in the .blend relative and then send all the files in such a way that relative paths hold even after transfer. We need to make sure that nothing in the directory we are sending depends on anything outside the directory.

Relative paths make sense mainly for custom farms

This is overcomplicated for rendering on external commercial render farms but might make sense if you run your own rendering solution. Especially if you are using different operating systems - e.g. Windows for your workstations and Linux for the render workers.

flowchart LR subgraph main [main.blend] scene end subgraph other [other.blend] scene --> object1 object1 --> object1_mesh scene --> object2 object2 --> ... end subgraph texture [texture.png] object1 --> texture.png end

Splitting up Scenes

Consider splitting up huge scenes into multiple files. This is especially helpful when rendering animations. You can render each "camera take" from a different .blend file and cut the final video in a video editing application.