.webp)
In the first part of this guide we talked about various online farms types, cloud rendering service workflows, 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.
From a render 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.
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 trouble 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:
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.
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 across the whole frame range. 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.
All render engines can generate artifacts, especially when the quality settings are set too low. GI solving methods that 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.
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:
The parts which cause render time to increase proportionally to the resolution are
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:
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.
In general, it’s better to test 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.
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.
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 that don’t use pre-cached GI. The rendering time is more tricky but most 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!
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/blog
