Please tell us a little bit about yourself, your background and your history in the industry.
I went to school to be an architect. I always loved to draw and thought that architecture primarily consisted of drawing. I was lucky enough to be at the NC State School of Design in the early eighties just as computer graphics was getting started, and as it turns out, I enjoyed the graphical and presentation side of architecture a lot more than the actual building of things. In my final semester, I was able to use a 3D modeling system on an independent study project where I visualized potential changes the state capitol city would see if they had alternative zoning laws. I knew then that computer-based visualization was the future direction for all design fields and immediately switched over from traditional hand drawing to doing everything on a PC. AutoCAD 2.18 was just out, and the IBM AT with an internal hard drive had just been released, so I started right out of school as a CAD manager for Ligon B. Flynn Architects -- a small custom home design firm on the coast of North Carolina.
15 – 20 minute screen re-draws meant many long nights in the School of Design Simulation Lab.
3D slideshow fly-through of Raleigh, N.C.
AutoCAD 2.x elevation of Thalian Hall, Wilmington N.C.
Coming from an Architectural background what was the impetus to start PipelineFX? Why leave architecture?
I actually left architecture in 1989 when I started the first plotting service in Hawaii using a Mutoh pencil plotter. I was plotting in pencil on vellum – it was just the coolest thing! My business partner was also selling systems and networking to architects and engineers so I became the AutoCAD “demo and training guy” in addition to my role as a plotting services provider. The business grew into a full Autodesk reseller with a focus on 3D animation (SGI, Alias, Wavefront, Avid, Parallax, Xaos Tools, etc…).
Then in 1998, Square USA came to Hawaii to open a film studio. We worked with Square for over five years to build a state-of-the-art feature film animation studio, providing everything from equipment to software to support services that would help them design real-time film playback systems, and custom build both desktops and render nodes. It was a terrific learning experience for me and I came to understand the inner workings of a feature film pipeline.
Can you tell us about Qube! (what it is) and how its evolved over the last 10 years?
Qube! was originally written for Square USA’s Honolulu studio while they were creating the feature film, “Final Fantasy: The Spirits Within.” “Final Fantasy” was the first animated film that attempted to show realistic human characters. Before that we’d only had bugs, ants and toys. This required a huge render farm (2,000+ machines) and lot of intelligent software design to maximize throughput and minimize the impact of huge scene files. And since Square had a large R&D department, they had the ability to write a lot of great software – including what would become Qube!.
We built a custom render farm of Linux nodes, 240 machines per bank.
When their parent company decided to close the studio, my partner at the time and I bought the code for their render manager and commercialized it. Of course it took several years and several rounds of angel and venture capital to convert what was an in-house toolset into a real commercial product.
The evolution of Qube! went something like this:
1. Re-write the whole product
2. Create installers
3. Create a GUI for easy administration
4. Document everything
5. Begin to sell the software and get customer feedback
6. Create job types and interfaces to many creative apps
7. Begin certification training and consulting worldwide
8. Focus on ease of use
9. Focus on stability
10. Focus on scalability
So, today we have over 600 customers rendering on more than 25,000 machines, and our software is running on more than 100,000 workstations and servers. Our base package starts at 5 workers (machines doing rendering) and our largest customer has 2,000 machines.
Generally you find more complex pipelines in the VFX arena, but as visualization pipelines mature they are becoming more difficult to manage. Are you seeing any similarities between VFX and Arch Viz pipelines?
Yes, you are starting to see design visualization firms using a variety of multimedia software such as AfterEffects, Cinema 4D, 3D Studio Max, Maya and sometimes Nuke. We are also seeing quite a bit of Maxwell Render. So as soon as a design firm needs to render with more than one application the free built-in renderer managers can't support those. In order to maximize the compute power of both the desktops and render nodes in a design firm, you really need a commercial render management application.
I actually think render pipelines are becoming easier to manage due to the availability of infrastructure software. Design firms can now buy render managers that don't require programming or customization and can support all of their software applications right out of the box.
But in terms of design firms that are moving from individuals managing their own rendering to coordinating network rendering for the first time, it can seem quite complex. That's why we provide consulting services and certification training classes to get folks up to speed as soon as possible on this new world of network rendering.
Are there advantages for smaller companies or architectural firms to leverage Qube! or is the value only for those who have very large dedicated render farms?
There are several important advantages to running Qube! in a small firm. The first is cost. If you only have five machines, the software is a relatively small investment compared to the application software, workstations, the render nodes, the networking, and the storage. All of which are required to do the rendering.
The second is you get everything you need to do network rendering across all of your applications right out of the box.
Next is world-class technical support. We consider rendering to be business-critical and when you purchase Qube!, you are gaining the PipelineFX technical support team.
Another critical benefit of running a mature professional render manager like Qube! is simply stability. The results are much more predictable and you will get a greater percentage of your work rendered without incident more often. In small firms with tight deadlines, this can make all the difference.
Why not just use backburner and let people enable access to their machines when they are not using it or when they log out?
Backburner is fine for the limited list of applications it supports as long as you are providing your own technical support and have no need to integrate other software packages. But the minute you would like to render with one more program, or you need any technical assistance in a short timeframe, it's better to upgrade to a commercial package. We consider Backburner and the other bundled render managers as utilities – useful for individuals running single applications, but not well-suited to groups that run multiple applications and require timely technical support. Many times, design firms are basically consultants that help clients figure things out. PipelineFX also provides remote installation services and on-site consulting services to make sure things are set up correctly and optimized in the shortest ramp up period. Our Qube! JumpStart service takes only four hours and is done remotely. At the end of those four hours, the customer is up and running and rendering over the network. In a small firm where there is perhaps no dedicated IT person, it is difficult to afford the time it would take implement a new render manager and get things going quickly. JumpStart answers this in a definitive and timely way.
From an ROI perspective what is the best way to look at an investment into your solution?
The bottom line on ROI is that if you aren't maximizing the rendering throughput of everything you already own, you may get talked into purchasing additional servers networking and rendering licenses to try to speed things up when really all you need is a higher utilization rate across your existing infrastructure. Many of our clients had planned to add machines and software that cost many times the price of Qube!, but once they upgraded the render manager and began to share resources /optimize the use of CPU cores and memory, the extra equipment was unnecessary. So, in many cases, the ROI's immediate.
Squint/Opera recently announced their implementation of Qube! into their pipeline for their Olympic projects. Are the ways they implemented Qube! pretty standard or did they require more of a customized solution?
Squint/Opera has a pretty advanced pipeline for an arch-viz firm. They have a dedicated person who takes care of their farm, their software and customizes and automates their processes to manage large scale, highly complex models and renderings. They had a very advanced Backburner-based farm before but needed to take things to the next level. We did a few tweaks to our 3ds Max submission interface for them and have since rolled those improvements into our standard product. Other than that, they are running a standard Qube! install.
Are you finding that the architectural market is becoming more interested in this type of pipeline solutions?
The design market is still slowly moving toward 3D visualization. It’s been a slow march for 25 years. But these days firms that enter competitions must have top notch multi-media presentations. And desktops are so powerful that 3D is easier to integrate into the design process. But until architectural schools, and high schools embrace 3D visualization as standard tool, we won’t see 3D used as much as I think it should be in the design and client communication process.
Are there any features that have been added specifically to address the architectural market?
As I mentioned Squint/Opera helped us greatly improve our 3ds Max interface.
We also created a small application we call QBlocker. It runs on the architects’ desktop and allows the user to add or subtract CPU cores to the shared render farm by moving the slider bar. You can also see what jobs are running on your desktop and purge those jobs if you need to use the whole machine. QBlocker has allowed desktop users to feel much better about sharing their multicore CPUs even during the day while they're working.
Another feature we recently added is worker side path translation. Many architectural firms are mostly Windows-based, but with larger render farms the cost of the operating system licensing can lead firms to deploy Linux on their dedicated rendering machines. There are also always a few OSX machines around. So our new backend path translation allows a job to land on any available machine regardless of the operating system.
What’s the most difficult problem you’ve had to solve in the last ten years while running PipelineFX?
Providing a truly out-of-the-box complete render farm management system. In the beginning we thought most customers would want to customize their render manager because there really wasn’t a standard render pipeline. As an example, when I started with AutoCAD in 1986 there was only a command reference manual. There were no books on AutoCAD at the bookstore, of course there was no Internet, and there were no training classes or university courses you could take on the software.
The same is true of render pipelines today. Search Amazon.com for render farm management or render pipeline books. We are still in the early days of render pipelines. But as it turns out most customers want to just use the software right out of the box. So we've developed multiple graphical user interfaces designed for both technical directors and IT people, and one designed specifically for artists or designers. We've built-in reporting and secure systems for viewing your render pipeline on the Internet. We ship submission interfaces to all the creative applications and support all three major operating systems.
Rendering is complex and render farm management and render pipelines are just hard. So providing something out of the box that works for almost everyone has really been the challenge. I think we've been pretty successful at that as our average customer renders on about 30 machines. Hundreds of our customers have no dedicated IT or programming expertise on staff and with Qube! they still manage very well. We will be introducing a new global installer at NAB this year, which is another step to making the software easier to install and configure.
Where do you want to see the company in the next ten years? What opportunities and challenges have yet to be attained?
I’d like to see PipelineFX continue to grow and provide even more training and consulting services worldwide. Education and assistance in setting up and managing render pipelines is really what's needed. Many render management systems will basically get the job done but it's the unique combination of stability, scalability, support, training and consulting services that makes our clients successful. And although over 200 schools currently use our software, there are thousands more that could benefit from professional render management. We see a huge opportunity going forward in the education market.
Who is your favorite Architect and favorite building/design?
I studied Le Corbusier in school and really love the Monastery of La Tourette. I became good friends with one of my architecture professors, Vernon Shogren, who was also a Corbu fan. Vernon supported my use of computer graphics when many other faculty members, including the head of the school of architecture, did not. Vernon and Ligon were long time friends so when Vernon got a call from Ligon to send a graduate that “knew computers,” Vernon sent me down to Wilmington to interview. My 3D work with Vernon got me the job and started my career in computer graphics.
I worked for Ligon Flynn F.A.I.A from 1986 until I moved to Hawaii at the end of 1987. He was a very traditional architect, endlessly scribbling with colored flair pens on yellow tracing paper. We developed a good back and forth relationship with me providing accurate site plans, property lines, setbacks, tree locations and providing structure to his scribbles. I’d produce a variety of CAD drawings at different scales for him to scribble over and then he’d explain what looked like a black ball of wiggly lines and I’d do my best to draw it in AutoCAD with some real world dimensions and order. Ligon was not threatened by CAD systems. He saw them as just tools of the trade to help figure out what a house or a building needs to be.
You must be logged in to post a comment. Login here.