David Merrell cooked up an idea to export UV data in some of our scenes. This example, from Perfect Little Planet, shows space available for licensee branding or a sponsorship message. The UV pass allows us to add mapped graphics without re-rendering the 3D scene. In other words: We can very easily put a licensee or sponsor logo into the show.

We’re employing a similar technique in Accidental Astronauts for improved lip-sync across languages, along with end-user branding and messaging opportunities.

Contact Andrea Doubek for more info.

ADoubek@slco.org
+1 385 468 1239

David Merrell cooked up an idea to export UV data in some of our scenes. This example, from Perfect Little Planet, shows space available for licensee branding or a sponsorship message. The UV pass allows us to add mapped graphics without re-rendering the 3D scene. In other words: We can very easily put a licensee or sponsor logo into the show.
We’re employing a similar technique in Accidental Astronauts for improved lip-sync across languages, along with end-user branding and messaging opportunities.
Contact Andrea Doubek for more info.
ADoubek@slco.org+1 385 468 1239 High-res

The Importance of Prototyping When Building Your Render Farm

Sometimes when you’re speccing (making specifications) for new computers, there’s a stand out candidate. Other times, it takes testing and validation to make sure you’re getting the best return. We’ve been through several different upgrade cycles at the Clark Planetarium so thought it would be good to give an idea into how those conclusions are made.
 
There are a wealth of good hardware blogs about servers, gaming computers and networking. The challenge is to find what benchmarks are going to tell you what hardware is best for you. What’s torture is when there is a new refresh happening at the time your budget is cycling. You can build based on well known CPUs (risk losing out on huge leaps on ROI) or build and try your luck. We got caught on the losing end.
 
We needed to determine the next render node type and AMD had just released their “bulldozer” class of CPU. On paper it looked like the CPU to beat all CPUs. No benchmarks were coming out that talked about rendering with 3DSMax or Maya. There were multithread tests that really took advantage of the architecture, with the caveat that you needed to disable the hyperthreading (should have been the first warning, but promises were made that it would resolve with a Windows patch). I built a test machine based on what would be the best ROI for the render nodes. What a sad sad sad story that was. The rendering was slow. Much slower than a high clock 8 core dual CPU system should be. Later it came out that 3DSMax uses special commands unique to the Intel cpus and heavily relies on floating point compute (of which bulldoze only contained 4 per CPU). The insult to injury came in finding out that 3DSMax was under utilizing the extra threads (at the time 4 was high efficiency, 12 was when a penalty would develop). This is very common to any program. It’s hard to efficiently scale across that many cores with complex instructions. The reason a penalty can develop is when a core is so loaded trying to keep all the other threads timed and executing efficiently, it can be the bottleneck. When the benchmarks for bulldozer rounded out, it looked like it would be a great server chip and not a renderer or workstation. The test-bed became our new central server where it’s doing a fantastic job.
 
Other times though you find that there is a huge gap between CPU types and the build is a no-brainer. Intel developed a 6 core, 12 thread processor that was performing like a champ. It rendered fast, was efficient, addressed a lot of RAM, overclocked well and we could get a fair number for about $2,000 per machine. They worked so well that we ended up swapping existing workstations into the render farm and using the boards and CPUs for workstations (which still join to render when not in use). Those situations can be rare though since we tried uping the game in the next build by using a dual cpu configuration as a test bed for the next build. We would end up with 12 cores, 24 threads. The motherboards for dual CPUs are not cheap, but if it worked, the return would be high. We could fit a lot of horsepower in a small space. The cost in software licenses also would be lower. Again the bottleneck was the software. 3DSMax would allow two copies to launch at once but the penalty developed still. It would be a lot cheaper to buy the single cpu configuration that had worked before, so we did.
 
And here we are at our current refresh cycle. There was no essential difference between getting a lot more of a 4 core, 8 thread type… and getting fewer 6 core, 12 thread type. The ROI was about the same. The 4 core type were built with less expensive board because the CPU was intended by Intel for home machines. The 6 core type needed a more expensive board, a GPU and RAM. Both would be highly efficient. They would fit in existing space and cooling constraints. What to do, what to do. As luck would have it, Intel announced they’d succeeded in making a higher clocked version of the 4 core. Usually when they do this, the price is so exorbitant that it’s not worth it. So I bided my time. When the prices were announced, it was a trivial cost increase. The build became a no brainer. The CPUs were listed as 4Ghz, but the motherboard clocks them up automatically to 4.6Ghz until it gets to hot (clocks back down to 4Ghz). Initial benchmarks from others had indicated it would be effectively equivalent to the 6 core even though it had fewer threads, so that’s what we expected. The cost to benefit was sealed. So we ran our own benchmarks based on our typical renders. It was shaving a third of the time off of renders. We were floored. We’d found a harmony between the threading ability of 3DSMax and price.
 
There are many ways to make higher thread system builds work, and in some cases they might be best for your software (server software loves high thread count, Maya will scale well up to 12 and not penalize till 16-18 depending). There’s even virtualization software that will instance your entire rendering process so that you can do double duty in one machine. The cost of the software and the overhead of the software divvying up resources between the two is an additional burden. Each need is unique. Finding the one that scales to you can be hard, especially without a good understanding of the variables.
—David Merrell