online render farm, render farm workflow, render farm tips

How to use online render farms part 2

And save time, money, eliminate stress and maximize your earning potential with cloud rendering

Contents

  1. Why small changes to a scene make a 100% different scene
  2. Running Tests
  3. Test with a step
  4. Flicker/noise test
  5. Testing still images
  6. Low resolution animation test
  7. Time estimation and priorities
  8. Summary

In the first part of this guide we talked about various online farms types, cloud rendering service workflow, general cost and time estimation procedures and necessary preparations before rendering.

In this part we will go deeper into testing techniques which are a very important step of an online farm’s workflow.

1. Why small changes to a scene make a 100% different scene

From a farm’s point of view, a scene with even a little change is a different scene. It doesn’t mean that it will happen often, but it can happen that this particular little change causes an unexpected change in the rendered image or in the rendered time and cost. It’s the same thing which sometimes happens on your computer as you progress with scene iterations.

That’s why it’s important to run a test of the scene on the farm even if you’ve made such a seemingly small change. If you are rendering a lot of small projects this might not be worth the effort, but if you want to render a different variant of something big, it’s good to double check. Ultimately, the decision is up to you.

TIP: The farm’s job is to render the scene exactly the way it renders on your end. If your scene has problems with proper rendering on your end, it most probably won’t render correctly on the farm.

2. Running tests

If there is one thing that can help you to use a render farm quickly, cost efficiently and without issues, it is running a test of your scene on a farm before rendering the full frame range animation or full resolution still shot.

There are several reasons why it’s so important.

From a user’s perspective, the whole process looks pretty easy. You have a scene which you tested, it looks great and it’s ready for production rendering. If you had troubles with it, you solved them and now everything renders fine on your computer.

However, no matter how simple a render farm workflow is, some random issues may appear:

  • You may not use the exact same build of 3d software as the farm does.
  • Some software features work fine from the graphic user interface, but might not work the same from command line rendering or network rendering options which are used by farms.
  • All 3d software has its bugs which are sometimes possible or not possible to fix by a render farm, so the support team needs to find workarounds (if a support team exists at all on the farm you are using).

TIP: The farm’s support can notice obvious problems, but you know your project the best and only you can check if the frames look exactly like the tests on your computer.

Luckily, there are easy ways to get a proper estimate for rendering time and cost on a render farm, even with all above factors included. As a bonus, they filter out all possible issues which you can experience, without losing time and money.

NOTE: Below are testing methods often used by estimation systems on render farms. It’s good to understand how they work, but you can use them also when you rent a server or even render on your home computer.

3. Test with a step.

Testing one or several frames of animation before final rendering is a very good habit. However, you can
do it in a way that will give a basis for a close cost estimate and help to preview the quality of the whole sequence before final rendering.

Why is step better? Because it will render test frames spread evenly along the whole framerange. This way it will take into account all the animation’s parts and their render times (think the classic Star Wars intro).

EXAMPLE: If you want to render a frame range of 1 to 400, you can render every 20th frame as a step, so you will get 20 test frames spread evenly along the sequence.

If you take an average cost for one frame from this range, and multiply it by the number of frames in the sequence – you will get a cost estimate for rendering the whole animation.

If you take an average rendertime for one frame from this range, and multiply it by the total number of frames – you will get the total time of rendering all frames. Since many nodes are rendering, the real time of rendering the project will be proportionally shorter.

EXAMPLE: I rendered a test of 100 frames with step 20, and got 5 test frames with costs $0.90, $1, $1, $1, $1.10. Average cost per frame is $1, so rendering the whole range will cost around $100.

TIP: How many frames to test?
In general it’s good to test at least 20 frames from the whole range. For longer ranges, more frames are needed, because some longer rendering frames can be located between test frames. A step bigger than every 100th frame may give inaccurate estimate.Rendering every 20th frame as a test is a good practice.

TIP: Using priority
If you don’t want to wait long for the test frames, you can use the highest farm’s priority for the test and then render the whole range on a lower one. Most render farms offer such priority plans, and the cost of the test is just a fraction of the cost of the full render. Also, if the test went well, you can skip test frames in the final rendering.

4. Flicker/noise test

All render engines can generate artefacts, especially when the quality settings are set too low. GI solving methods which create approximated irradiance caches can cause splotches. Brute force/QMC/Path Tracing engines can render with noise.

Those effects are even more visible in animations than in still images since their distribution changes from frame to frame. It especially concerns distributed rendering because every frame is rendered on a different computer which solves the GI calculation a little differently.

This is why it’s good to run a ‘flicker test’ of 5-20 consecutive frames before the final rendering, and check if they animate well.

In some cases, a bake/pre-cache of GI will be needed to get rid of imperfections. Many farms support automatic caching of the most popular irradiance cache GI solvers, but you can also use the cache generated on your computer.

If your rendering power is not enough, you can prepare GI baking ( or any other kind of time-consuming caches ) using remote access to one of the farm’s servers.

Rendering artifacts like GI splotches or noise which would be acceptable in still images, can cause ‘flickering’ effect in animations. After running a ‘flicker test’ it is sometimes necessary to increase the quality settings or use GI baking or denoising options.

TIP: Caching simulations
The safest way to render all kinds of simulations on a render farm is to use pre-cached files linked in the project in “Load” mode. Some simulation applications don’t give a different option, but even if the simulation can be rendered “on the fly”, rendering pre-cached files is more stable in network rendering. If your cache folder is so big that it takes a very long time to upload, you can rent the farm’s node and generate the caches on farm’s end.

5. Testing Stills

If you want to get an estimate for the cost and rendering time of a still image, and get a sample of how the scene renders on a render farm, it’s good to run a low-resolution test first.

Based on such test you can calculate an estimated cost for the full resolution.

For example, if your final render will be 2000x2000px, you can run a test in 500x500px. The estimate for the final cost will be around 16 times bigger than the cost of the test. It’s good to not go lower than ¼ – ⅕ resolution for a test.

The render time of still images rendered in various resolutions doesn’t always scale linearly. Because of that, a test of still images may not be as accurate as animation tests with step.

Every rendering process on a render farm can be split into two parts: The part which is independent of resolution and the part which is:

For example, for V-Ray rendering with Light Cache + Irradiance Map, the parts which are independent of resolution are:

  • loading the project to node
  • opening in 3d application
  • preprocessing time ( preparing geometry, pre-rendering )
  • Light Cache calculation ( if there is enough of RAM for displacement )

The parts which cause render time to increase proportionally to the resolution are

  • Irradiance Map calculation
  • Final rendering
  • Saving outputs
  • Scene’s features which require lot of RAM, especially displacement

Let’s have a look at how it can affect the estimations based on low resolution tests:

Sometimes a low resolution test can give estimates which are lower than the final time and cost of rendering of a still image, because the rendering time grows very quickly with the resolution.

Here are some examples:

  • Light cache rendering with Displacement based on resolution in V-Ray
  • Scenes with high quality blurred reflections, reflecting each other ( like a car spoiler )
  • Scenes with multiple layers of blurred refraction or SSS.
  • Any scenes which use quality settings dependant on the resolution

There is no point in going too deep into such calculations during everyday online render farm use. It’s just good to keep in mind that still resolution tests could not scale in a directly proportional relationship to the resolution and it’s good not to set too low a test resolution.

TIP: You shouldn’t go lower than 1/5 of your resolution at the risk of getting an overblown cost and time estimate. Ideally, it’s good to run a test in as big resolution as possible, but ½ res test may render too long and cost too much. Usually, a test in ¼ of the final resolution is the best choice.

TIP: Hanging last buckets – set smaller buckets for long rendering reflections
In bucket rendering it might happen that the last buckets will stay very long on some time-consuming parts of the scene, like complicated shaders or high-quality glossy reflections. It can happen especially with stills, as you render them for the first time in the final resolution on a render farm. If you know that your project has such parts, it’s good to set it to rendering with a very small bucket size. Sometimes optimization is needed ( like cutting the number of reflections or refractions ).

6. Low resolution animation test

In general, it’s better to test an animation with a step than using low resolution. The reasons are similar to testing still images. These kind of tests are useful only if you want to see a preview of your animation or show it to your client.

Smaller frames might not give you enough information to decide if everything is ready for final rendering. Finally, such tests are usually more expensive than tests with step, and you can’t use those frames as a part of the final animation.

TIP: Use limits for progressive rendering
When you are rendering an image with progressive rendering, you need to set a limit for the engine to know when it should stop rendering. The best option is to use a noise or passes limit. A render farm will most likely render your scene on nodes with different power than your computer’s. If they render with the same time limit as on your computer, the nodes which are faster than your machine will render the same amount of time so the image will have better quality, but can cost more than it is necessary. Nodes which are slower may not reach the quality level of the frames rendered on your computer in the given time.

Online farms infrastructure covers not only rendering nodes but also data storage and managing. On the left – a network of hard drives, on the right – a rack with managing servers like a file server, license servers and other.

7. Time estimation and priorities.

This part is more tricky because the time in which you will get your frames doesn’t depend only on stable factors like your project’s volume and number of used nodes. It is also dependant on the current farm load, and so it changes dynamically.

Many render farms offer rendering priorities which can help you balance price and get the frames as soon as possible. Priorities will determine how many nodes are allocated to your project, and where your job sits in the render queue.

TIP: If you have run your estimation test on a given priority, it’s usually very simple to calculate the cost for another, since they are multiples of the same price.

Modern rendefarms support not only CPU but also GPU rendering – either as a cloud service or by renting powerful GPU servers with a remote access.

8. Summary

Render farms are the ultimate time saver and a good choice for those who don’t want to invest in an expensive network of computers. Also, even studios which use their own farm need more computing power from time to time.

As is the case with any service, it’s good to test a render farm before committing. Your scenes can encounter some issues during rendering, because they are rendered in a different environment. The render farm cost calculators are a good way to get a rough estimate, but for technical reasons, it’s better to run a proper test of your project.

Testing animation with a step and running a low-resolution test of a still image will help you to get a close cost estimate for your final rendering, and check if your scene works well on a farm’s network. A test of several consecutive frames helps to avoid flickering in animations which don’t use pre-cached GI. The rendering time is more tricky but Cloud Services job management tools make them easy to track and change the priority if needed.

Finally, an experienced support team is happy to help, so don’t hesitate to express any questions or concerns to them.

I hope the workflows and tips described in this guide will help you spend your money as efficiently as possible, and save time for the most important part – creating art.

Happy rendering!

It is scientifically proven that kittens can detect overheating nodes with 99% accuracy.

Sources

Useful links

Credits

This guide has been created by Michał Moś and edited with the help of the team at GarageFarm.NET. We derived most of the knowledge used in this guide from an extensive experience running a render farm for almost a decade.

Michał Moś ( aka ‘Andrew’ ) is part of GarageFarm.NET team specializing in 3d rendering topics from animation and troubleshooting to technical writing. He has worked for numerous design and architectural companies as a CG artist, designer, and instructor. Weapon of choice – 3ds Max, C4D, V-Ray and Octane. He loves drawing, creative writing, and tabletop RPGs.

https://michalmos.carbonmade.com
https://garagefarm.net/