At PipelineFX I have made supporting digital media education programs a focus and with over 200 universities and school around the world already managing their rendering infrastructure with Qube! we are making great progress in that area. Many schools are still leaving rendering to be managed by each individual student and using the post-it note method of writing “Stay off my machine! Rendering!” These programs have not yet recognized the importance of rendering in the digital media education process. I’d like to share my views and experience on this subject.
In 1986, while finishing a Bachelor of Environmental Design in Architecture at North Carolina State University, I attempted an independent study using a fancy mini computer, a digitizing table and some alpha solid modeling software donated to the school by a local engineering firm. My premise was that computers and specifically 3D animation and visualization would allow non-design professionals to understand the possible consequences of zoning laws on the built environment. In short, when lawmakers say how dense and how high buildings can be, twenty years later you have certain kind of city. What that city looks like and to some extent “feels” like could be anticipated via computer modeling and simulation.
So focused armed with the energy of youth and a clip board and measuring tape I proceeded to walk 36 blocks of downtown Raleigh N.C., stepping off the foot print of every building, noting materials and colors and guesstimating their heights. Ten class volunteers helped me and after two days of this and 60 pages of notes I returned to the Simulation Lab and my seat at a Cadmus mini-computer and began digitizing the site plan of those same 36 blocks as a footprint for the “as built” version of my Raleigh model. The OS was Unix, the software very simple, and everything was commandline. But the display was a 19” 24-bit color Rastergraphics and after a very slow re-draw the model was coming to life.
First I focused on creating the as-built model, then defining different zoning laws that might be implemented and were reasonable but would clearly result in a different looking capitol city. One was a “high-density on the capitol mall only” set of laws and the other was a “nine-square” rule that spread high buildings out across all of downtown. Then I designed the future cities to follow these rules, as well as take into account real world factors such as existing empty lots, the age of existing buildings and the likelihood of them being preserved for the next twenty years or being replaced.
Now to create these models I needed to “render” still images from different camera viewpoints, checking the colors and geometry of each building and road. In the first month of a four month project the screen re-drew in two to ten minutes. By month three, with all models complete, I was faced with thirty minute screen re-draws, or ‘renders.” Now the deliverable of this independent study was a slide show moving through these different models, allowing the viewer to experience the city of today and two possible cities of tomorrow. With 30 minute renders per camera location, and a desire to have many images to “dissolve” together to simulate animation and movement I realized I would need to almost move into the sim lab and sleep next the system, waking every hour or two to re-position the camera and start another screen render, sleep, wake up, take a photo (yes, 35mm slide film, I know, I know…), move the camera, back to sleep….for two months!
Even to show my professor my work each week was too render intensive to prepare much. I’d have a render done to discuss then move the camera once and we’d talk for half an hour while the screen painted line by line. Even then it was clear to me that once we begin using computers and rendered images as a critical part of a design project, the time to render is THE bottleneck in the review, critique, and re-work cycle. The amount of critical feedback from faculty, peers and even myself was limited by the number of times I could make decisions, implement those decisions in the model, and re-render the necessary images in the time allotted. Any increase in rendering speed would directly benefit the project by providing more opportunity for review, thought and change, resulting in a better overall project and more compelling presentation.
Even given the challenges of early computing hardware and software I was excited about the possibilities of visual simulation in design. The accuracy, ease of perspective display, and just hi-tech look of the imagery foretold a useful place in any designers toolkit. Today design professionals, post production houses, broadcast television stations, visual effect studios and film makers around the world use computers and software to create, advertise, entertain, inform and amaze their clients and audiences every day.
In the education field computer graphics systems are not relegated to the graduate area of a simulation lab with limited student access. Labs are filled with multi-core desktops running Maya and Nuke, whole Mac labs running AfterEffects, editing labs with Avid and FinalCut, and even dedicated render farms are being built as a shared resource across an entire digital media program. Schools are deploying render management solutions to maximize the use of their computing resources and simplify the use and administration of the rendering process. Advanced render management systems like Qube! allow labs to share resources yet retain priority for their own users, making sure every CPU is processing someone’s project, reducing that creative loop and increasing the overall educational experience of every student.
Another recent challenge is transcoding. Students are beginning to shoot film on digital cameras like RED. To ingest the RED footage can take days on a single machine, and though there are special accelerator solutions the sheer amount of data can still delay time begin editing and review for many hours if not days. Distributing the transcoding across many machines reduces that delay dramatically. Advanced render managers manage the transcoding process as a job the same as any 3D render of 2D composite and divide the work across many computers. Students can begin editing much sooner and can re-shoot parts that require it much earlier.
Render times were the bottleneck to my design project in 1986, and in my opinion remain the primary bottleneck to improving the digital media education experience of students today. HD formats and stereoscopic rendering have recently exacerbated this problem. The good news is that by deploying a smart render manager and harnessing existing computing resources the iterative cycle can be reduced significantly with little expense. Once a program has all of it’s computers working at high utilization rates (which you should know from the reports your render manager provides) then budgets can be planned for a dedicated but shared render farm. It is interesting to note that as of this writing I am finding that China leads the way in dedicated render farms for digital media education, commonly deploying fifty to one hundred or more dedicated rendering servers per school. The Chinese government funds these schools and they run classes nearly 24 hours a day. they have recognized the importance of rendering in the feedback loop of their teachers and students and devote budget and staff to making sure that loop is as short as possible.
As I visit schools around the world this message is well received and changes embraced to improve the iterative cycle and maximize existing investments in infrastructure and computing power. Simply deploying smart render management is a huge step in the right direction.
