Streamline your render passes
Brian Welsh
Senior Producer
UVPHACTORY/NY
Recent HD Projects: IDs for VOOM and Madison Square Garden
The HD canvas is nearly six times denser in pixel information than the SD resolution screen — a dramatic increase to the file size of projects if they’re HD deliverables. Unfortunately, clients’ production schedules for HD projects are generally the same as for SD-resolution projects. This often makes for long nights tending the render farm.
There are practical and cost-effective solutions that can expedite file and render management throughout the production process. With more people working on larger scenes and comps for HD projects, it became evident that we needed a network that would adequately handle our file management and batch-rendering of larger files. The installation of a Gigabit Ethernet (1000BaseT) network has dramatically lessened our render time as well as streamlining file management.
Another way to make HD projects a bit more manageable is to be clear from the beginning of a project about how you will deal with the number of 3D passes for each scene. A seemingly minimal client change can affect numerous passes that must all be re-rendered. Using intelligent and practical grouping of elements in render passes can save valuable time.
Evaluate your network backbone and get ready to upgrade
Rich Torpey
VP, Engineering
MVG (Rhinopost, Rhinoedit, Rhinofx, Meccanica and Tonic/NY)
Recent HD Projects: Monsters, Bowling for Columbine, 100 Center Street
To address the dual issues of moving larger files and allowing more people to use them, we identified bottlenecks and found a combination of hardware limitations and workflow methods. Servers, tape back-ups and the network backbone that had been adequate for SD (at approximately 1 MB per frame) crumbled under the load of HD video and film resolution material at 7 to 20 MB per-frame.
Our first step was to improve the throughput of our network backbone, first to Gigabit Ethernet (1000BaseT) then recently, we quadrupled capacity using multiple Gigabit Ethernet lines combined to create a 4 GB backbone for production and a separate gigabit backbone for administration.
Larger image sizes means longer renders. If your render nodes don’t have enough memory, they may start using hard disk space instead of RAM, which can slow down processing 20 times or more. Next we added larger and faster fileservers, building our own Linux-based servers then adding a customized Maximum-Throughput Sledgehammer for use in the more demanding applications. The greatest load we had was several dozen artists trying to use a single fileserver for source and output files— splitting the load among multiple servers allows us to scale up when needed.
Store and move footage on firewire drives
Conrad W. Denke
CEO
Victory Studios/Seattle
Recent HD projects: Spots for Tulalip Casino, Spectres
Two of the most important issues to deal with for storage are size and bandwidth. One frame of uncompressed 8-bit 1920x1080 4:2:2 HD footage will fill 4.15 MB. At 30 fps that’s about 7.5 GB for one minute. Compare that to standard def 8-bit 720x480 4:2:2 where that same 7.5 GB could store six minutes of footage. Storage requirements can get even larger if you go to 10-bit, 4:4:4 sampling, higher frame rates, or higher spatial resolutions such as 2K or 4K.
The speed of accessing your storage medium is of equal concern. For uncompressed 4:2:2 HD, you need a storage system that can sustain record and playback at a bare minimum of 160 MB per second. If you don’t need real-time record or playout, you can store footage and move it around on other storage mediums. A favorite for us right now are off-the-shelf FireWire drives, which will soon be available in sizes of one terabyte and larger.
Post your comments below
