AUGIWorld Magazine - November/December 2008 - (Page 12) ARCHITECTURAL VISUALIZATION Building a Rendering Pipeline achieve it as well, allowing, to varying degrees, architectural renderings to be done in-house efficiently and effectively. What, suddenly, has happened to “raise the bar” on architectural visualization? Some say it is client demand—clients want and need to fully understand the design before anything is built. Others will argue that software and hardware are finally reaching a point where renderings are the norm, instead of being a luxury. As for me, I lean toward the thought that it may be a bit of both. Architectural rendering has matured into a sort of refined hybrid type media. Instead of conventional illustrations that are mostly technical in nature, visualization, in recent years, has taken on an almost cinematic approach to elucidating the design. Photorealism has become an industry expectation as opposed to a unique selling feature for the select few. Hardware In or out? One dilemma that persists for architects today is whether to do the rendering in-house or send it out. Most small firms, as well as some medium-sized companies, contract out renderings in lieu of buying up the necessary hardware and software and keeping a full-time visualization expert on staff. Large firms typically have staff and hardware in-house to fulfill their illustration needs, but may also contract out depending on workload or the scope of expertise required for a given project. Building an in-house rendering pipeline for architectural visualization is not only attainable for medium and large companies; small and single-person operations can There are three main areas to consider when building a rendering pipeline. The first is the render node. Render nodes are the workhorses of the whole operation. They can range from actual workstations to the secretary’s computer or even that dusty tower in the backroom that has the old plotter connected to it. Most modern rendering engines use bucket rendering, which allows many computers to work on a single image. The availability of these render nodes is of utmost importance when rendering is required. The best-case scenario is that the render nodes are built specifically for the task of rendering and nothing else—meaning there isn’t anyone else using them who may be annoyed when their programs are slowed because the rendering software basically takes over the system resources. This also means that monitors and video cards are not really a worthwhile expense since they have no contribution to the rendering speed. At least in the monetary sense, the focus should be placed primarily on RAM and fast processors. The worst-case scenario is that your access to render nodes consists of wrangling everyone’s computer as soon as they aren’t using it or have left for the evening. This causes some major time constraints if your only render nodes are those belonging to other people with their own work to finish. The most realistic scenario is that you have as many dedicated render nodes as you can afford and the ability to take over everyone else’s computer for rendering when it is not in use by the owner. It sounds excessive, but remember the old adage: “It’s better to have it and not need it than to need it and not have it.” The second area to consider is your server/file server. Your server will govern all the connections from all of the render nodes requesting tasks. The file server is typically the computer on which you store all of the material libraries and textures and 3D models used in the rendering process. It can also act as a storage area for image sequences that are rendered out for compositing or editing. Small operations, utilizing fewer than 10 computers total, can simply assign a specific machine as the “pseudo” server and work in a peer-to-peer fashion. This machine will be no different than any other machine on the network except by its designation. Since there is a 10-computer connection limit in Windows when going peerto-peer, any render pipeline that consists of more then 10 will need an actual server/ file server. The third area is storage. For the most part, mass storage is something that is handled by the server/file server, but NAS (network attached storage) devices are an alternative. The amount of storage and setup is relative to what is required, as well as what is justifiable financially. Hard drives are cheap and, again, it’s better to have too much than not enough. w w w. A U G I . c o m 12 http://www.augi.com
For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.