KeyShot is reliant on the CPU, but has a range of tools to quickly setup a render farm on localised machines
The rendering process: almost always required; always the last part of the puzzle; and always needed yesterday. Unless you’ve already faced these issues and invested in some sort of rendering capability, then you might be finding that your workstations are great for the day-to-day work of modelling and general CAD, but not so fast when it comes to rendering.
The big question for many firms is how to add more punch to the workfl ow without needing to replace an existing set-up. Thanks to developments in rendering hardware and software, there are multiple ways to achieve this goal.
The simplest is to move from a CPU- to a GPU-centric rendering workflow, adding a high-performance GPU to your machine. That could mean a GeForce GTX 1080Ti for small to medium-size datasets or a move to a full-blooded Quadro P6000 with 24GB vRAM. The latter will deal with most medium to large jobs and tackle concerns around memory limitations in GPU rendering.
If you really need to go extreme – and if your machine can handle the power – then the best option is a Quadro GP100, which allows you to utilise the new NVLink functionality to combine the memory from two cards to give a massive 32GB vRAM for rendering. It does, however, come with a hefty price tag.
This assumes, of course, that your renderer of choice can actually run on a GPU and isn’t CPU-bound. The list of programs off ering GPU rendering is long and includes Iray, V-Ray, Octane, Redshift, Maxwell, Fstorm, Clarisse IFX, SolidWorks Visualization (formerly Bunkspeed), FurryBall, Arion, Lightworks and Thea. Notable exceptions, however, include Keyshot and Arnold, although Marcus Fajardo of Arnold creator Solid Angle (now part of Autodesk) has demonstrated Arnold running on a GPU, so future versions may support it. Pixar has also announced XPU for Renderman, a hybrid CPU/GPU renderer.
The GPU route allows you to increase rendering performance within the confines of your machine, taking advantage of new renderers that are changing the way we perform this work today.
Rendering – Shared resource
If you need to move beyond workstation upgrades, or offer rendering to multiple users, however, then there are some big choices to be made. Distributed rendering is the next easiest solution. This involves buying another machine and utilising its compute to assist your main workstation. Unused workstations on the network can be used as slaves, sharing their compute resources to assist in local rendering. It’s not the most elegant solution and certainly not the most optimal way of rendering an image or sequence of images, but it is a way to do this.
Several products offer distributed rendering. The best known are V-Ray and V-Ray’s newer product, Swarm. Corona is also good and Luxion’s Keyshot offers similar capability. Other products have fallen by the wayside, including Mental Ray and Renderman’s REYES.
On the farm
The next level up from here is to implement a dedicated render farm with a render farm manager. A render farm is a collection of machines that have CPU, GPU and memory capable of producing images. The farm might be created from a number of old workstations sitting in the corner of a room or, in a more expensive approach, with rack-mounted server solutions that accommodate greater density of machines in a controlled, cooled environment.
Whether or not you go for CPU or GPU – it entirely depends on your workfl ow and renderer of choice – the render farm method requires more infrastructure to be successful. Centralised storage that your whole team works from becomes vitally important. This implies a network and storage solution that’s up to the task and has sufficiently enough performance so as not to annoy your artists to the point where they cheat, work locally again, and nullify the whole point of the render farm. Complaints that the render farm is “too slow” are a sure-fire sign that artists are tempted to revert to working locally – or have already done so.
However, when implemented properly, this set-up allows dedicated render farm machines to see project data at all times and to render on a 24/7 basis. It supports tiled rendering and jigsaw rendering, with the benefit of having job queues that enable better use of compute resources across an organisation or group of users. More advanced workfl ows and better execution of animation sequences finally become achievable. And it opens the doors to hybrid cloud workfl ows for ‘burst capacity’ on very large render jobs that come along every now and then – so that work can be shared between the render farm and processing resources out in the cloud.
The drawback is that a render farm approach incurs extra licensing costs and requires an understanding of pipelines and workfl ows that get the best from their infrastructure.
Whichever route you choose, the future of rendering is bright. This work is becoming an integral part of the process at all stages – not just a tool to win the job or to showcase a design, but also a vital weapon in the fight to communicate ideas. How you implement it to best advantage is entirely up to you.
escape-technology.com
Lee Danskin of Escape Technology talks rendering
Default
