Hacker News Reader

"For cinematic CG the models, textures and other assets are absolutely huge - it's not unusual for a single shot to come to hundreds of gigabytes."

I recall reading an article, IIRC in CineFX, about the Godzilla model in Gozilla 2000 (the Devlin and Emmerich film). The textures for their Godzilla model alone were something like 900 MB.

Honestly I wouldn't be surprised if Pixar introduced a renderfarm hosted in Azure.

Although the amount of data is very large, you don't general end up taking the bandwidth hit all at once. If you have your renderfarm set up on Azure, you could set up a plugin for your animation software, e.g. Maya, that uploads the assets for the scene you're working on and renders it on an Azure virtual machine configured with multiple processors, then download the rendered image data. One you upload the assets once, you will rarely if ever have to upload the whole lot of them again if the render management software is smart enough to keep track of which files you've modified since the last time you rendered. So you've modified a mesh but none of its textures, it only needs to upload the mesh in order to re-render.

It's hardly trivial, and for the larger shops like WETA Digital that are creating massive, virtual sets with massive, virtual armies modeled and rendered with Massive (couldn't resist :)), they can afford an in-house renderfarm -- and the costs will favor it.

For a smaller shop, that might not be so easy, BUT there are shops that are pulling off some pretty amazing animations without buying the pricey software... outfitting a renderfarm with Photorealistic RenderMan or Mental Ray or Final Render licenses can get quite expensive -- when last I checked, it was something like $2000 or $2500 per machine for a Mental Ray rendernode license. PhotoRealistic RenderMan was in the same price range.

WETA Digital uses Ubuntu Server on their server farm and desktops:

http://jordanopensource.org/freeplanet/article/ubuntu-linux-...

I'd hazard a bet that the type of servers deployed in cloud systems like Azure isn't really suited to large number crunching operations (such as rendering).

A good example of a big FX shop is WETA Digital (they did LOTR and Avatar) who own supercomputers at 279, 280, 281, 282, 283 and 413 on the Top 500 Supercomputer List. I'd be amazed if Azure had anywhere near that kind of power (in any kind of suitable configuration).

Too bad they didn't use EC2 to handle the Renderman Farm. They could have made it a bit easier by using Amazon Web Services own version of a sneakernet, http://aws.amazon.com/importexport/

Would cloud farms be practical if your assets lived on the cloud as well? That could solve the bandwidth problem both with the render cycle and collaboration with other shops.

Or would getting the assets there in the first place be impractical?

You're off the rails. If two things are "in the cloud" that can still mean they're in different data centers in opposite ends of the earth. The "cloud" just means outside your local lan. So it's the 99.999999...% of the internet you don't have any control of.

Meaning you'd still have bottle necks and bandwidth issues in getting them somewhere. That's why large projects just send HDDs.

This is just a proof of concept.

Just have creation tools that allow you to capture and replay input. Then to send that multi-gig mesh or texture, you just send the input events from the artist and replay it in another instance of that tool (think doom2 demo file; as a YouTube video it is hundreds of megs, as a demo file it is a few kb).

There's no way that would be at all productive. It's not like the only thing that the artist is doing is typing characters on a screen. There's also a lot more going on than just echoing pixels like in an IDE.

For a character animator, there's an IK rig which, depending on the character, can be quite complicated, and IK involves a lot of math. Then there's the mesh deformation and blended IK/FK. And then things like hair and cloth simulation. And texture rendering. Doing that on a cloud would have latencies that would make it excruciating to work with.

Compositing would be just as bad; the amount of data involved is larger, and as you add layers and masks, filters that affect those layers and masks, you can pretty much throw any hope of interactivity out the window. Now imagine trying to paint out safety wires over a cloud...

Digital art requires a LOT more computing power than creating software.

Try playing a first person shooter on a laggy network, you'll get a sense for how frustrating and counter-productive what you're suggesting would end up being, though I suspect that it's because you're vastly underestimating how much goes on in digital artists' tools more than anything else.

It was claimed that assets couldn't be sent to the cloud because they use too much bandwidth. I pointed out that sending a replay of events used to create assets takes very little bandwidth. This has nothing to do with the latency you are talking about here.

I think he's implying that the bottleneck won't be an issue if (when?) we eventually have web-based software powerful enough to create those assets entirely within the same "cloud" that would eventually scale out to do the rendering.

When things are in the cloud, they don't have to be in different data centers. Cloud providers are starting to provide tools that give you control over proximity for exactly these sorts of performance issues.

Pixar doesn't use Azure for it's production render pipeline, this is a deceptive marketing article showing proof of concept. THIS WOULD BE AMAZING if it worked, bandwidth is not an issue because each frame element texture and footage would never really top 1GB, the time is doing the Mental Ray/IBL CPU intense render. Here is what all of us VFX people want: Amazon EC2 render farms for Maya, Mental Ray, Nuke, 3DS, and whatever we can throw at it. Also a strict privacy policy- these renders could be one of the last steps in the composites......

The uploader does a diff between what was uploaded before and what you're uploading now and only sends what's needed.