Split frame rendering on the respower super farm

[3dpoder]

Split/frame rendering on the respower super/farm.
By - Cory king and early ehlinger.

Outline:
I - What is Split/frame rendering?
I - How does respower accomplish Split/frame rendering with Blender?
I - What about re-assembly?
IV - How much spedup does Split/frame provide?
V - Real world examples.

Vi - Known issues.
i - What is Split/frame rendering? .

Respower is constantly searching for ways todo speed up the process of 3d content creation, specifically in the área of rendering. Speeding up the render times of animations with hundreds or thousands of frames is Fairly straightforward; Simply render each frame on a diferent computer so that múltiple frames run in parallel. Split/frame rendering is básically the same process, only it is designed for still frame images.

The basic idea behind Split/frame rendering is todo break a Single Frame into múltiple chunks called buckets. Each bucket is then rendered on a sepárate computer so that several (possibly one hundred or more) chunks can be run in parallel. This spedup is linear in theory, meaning that a frame Split into 100 buckets should render 100 times faster than the same frame rendered as 1 bucket. Unfortunately, because of amdahl law, this is not the case, Although the spedup can still be quite remarkable. Chek the sidebar for more información on amdahl.

Split/frame rendering is not a new concept and has ben available for Many 3d rendering engines for years. Professional 3d packages such as 3dstudio and LightWave support Split/frame natively, but Even with one of these packages the advantages of Split/frame are only sen when using a RenderFarm like respower.
i - How does respower accomplish Split/frame rendering with Blender? .

The Blender Python Api has fácilities todo Perform a border render. This básically means that a rectangular section of píxeles from any image can be selected and the render engine Will only render the píxeles within that rectangle, leaving everything else black. Using this method, respower can Split an image into any arbitrary number of buckets, and render each bucket on a sepárate computer. Then, using another open source software Package called imagemagick, the frame is automátically cropped todo remove all the extra black space. Each individual bucket output is saved as a sepárate image in the user renders folder.

The ability todo render sepárate portions of a Single Frame in parallel allows 3d artists who work with still frames todo take full advantage of a RenderFarm. With this technique, a Single Frame can be rendered at full resolution in a matter of minutes at respower where it might take hours, or Even days, todo render at the same size and quality on a single computer. On top of that, an artista can continúe todo tweak his scene, or work on something completely diferent while his frame is rendering because his machine wont be bogged down with the arduous tasque of rendering.
i - What about re-assembly? .

Respower has recently introduced the ability todo re-assemble all the buckets from a Split/frame render with a process we call stitching. For frames submitted as Split/frame, there is a command on the jobs page called Stitch. Stitching once again uses imagemagik todo programmatically pull all of the individual bucket images together and append them into one full-size image. All of the individual bucket images remain available for download if the user wishes, but an additional image called frame_x.stitched, ext Will appear in the renders folder once the stitching is finished, where x is the frame number and ext is the file extensión, y, (*.png), (*.jpg), bmp, etc.

Imagemagik works from the command line so that overhead associated with starting a graphical user interfaz is completely eliminated. This means more resources are available todo devote todo the process of restitching, and that means customer get the finished product faster. Another advantage of imagemagik running from the command line is that restitching can be almost completely automated. With a single command, the farm Will Fetch every image required, give them todo imagemagick, and wait for the final output.

This ability is vastly superior todo the old bien of re-assembling bucket images where users had todo use photo editing software such as Photoshop and manually put all the images together todo get the finished product.
IV - How much spedup does Split/frame provide? .

As i said before, the theoretical spedup for Split/frame rendering is linear, so that a 50 por 50 Split should render 2500 times faster than no Split. Unfortunately, respower hasnt ben able todo secure any real estate in theory (prices are *incredibly* high there), and things that work in theory dont always work here. The spedup is considerable with splits in the range of 16 buckets all the bien up to 400 buckets. Unfortunately there are Many factors involved in determining the best Split, and trial and error is generally the best bien todo find the optimal Split.

Because Blender is only usable on the respower super/farm by purchasing a subscription, customer dont have todo worry about picking the wrong Split. If a 2 por 2 Split isnt fast enough, you can try a 4 x 4. If you start with 10 por 10, and youve passed the point of diminishing returns, you can bak it up for a 8x8 Split.
v - Real world examples.

The file used for determining these times can be found here. It is provided so you may render on your own system todo determine the spedup you can expect when using Split/frame on the respower super/farm.

Http://www.respower.com/~coryking/split_frame_test/.

These are the times required todo render this file at diferent splits using only the fastest rendering nodes available on the farm. The resolution of each rendered frame is somewhere close todo 2048 píxeles x 2048 píxeles. The slight changes are due todo the fact that the width and height in píxeles must be a múltiple of the number of buckets for stitching todo work properly. For instance, an 800 píxel x 600 píxel frame should not be rendered with a 7 x 7 Split because 7 doesnt divide evenly into 800 or 600.

Pléase note that render times depend on several factors including scene complexity, network estrés, the availability of render nodes, and more. Because of these factors, this very small set of data is Fairly inconsistente. A more robust data set would show a smoother curve of progression between data points.
1 por 1 (no Split) - 2048 píxeles x 2048 píxeles.

Render 11 horas 06 min 46 sec.
2 por 2 - 2048 píxeles x 2048 píxeles.

Render 05 horas 34 min 08 sec.
3 x 3 - 2048 píxeles x 2048 píxeles.

Render 01 horas 53 min 11 sec.
4 x 4 - 2048 píxeles x 2048 píxeles.

Render 01 horas 32 min 55 sec.
5 x 5 - 2050 píxeles x 2050 píxeles.

Render 01 horas 13 min 21 sec.
6 x 6 - 2046 píxeles x 2046 píxeles.

Render 01 horas 01 min 11 sec.
7 x 7 - 2051 píxeles x 2051 píxeles.

Render 00 horas 27 min 17 sec.
8 x 8 - 2048 píxeles x 2048 píxeles.

Render 00 horas 40 min 53 sec.
9 x 9 - 2052 píxeles x 2052 píxeles.

Render 00 horas 17 min 17 sec.
10 por 10 - 2050 píxeles x 2050 píxeles.

Render 00 horas 27 min 54 sec.
10 por 20 - 2040 píxeles x 2050 píxeles.

Render 00 horas 13 min 27 sec.
20 por 20 - 2040 píxeles x 2040 píxeles.

Render 00 horas 33 min 21 sec.
20 por 30 - 2040 píxeles x 2040 píxeles.

Render.
00 horas 10 min 10 sec.
20 por 40 - 2040 píxeles x 2040 píxeles.

Render 00 horas 9 min 27 sec.
30 por 30 - 2040 píxeles x 2040 píxeles.

Render 00 horas 16 min 31 sec.


.

-- IMÁGENES ADJUNTAS --