Why Pixar uses Microsoft's Azure

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?

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

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/

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).

"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.

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......

This might help: http://www.microsoft.com/windowsazure/evidence/

I recollect reading (no citation, sorry) that Vimeo has Windows instances running in EC2 in order to transcode video from Microsoft formats.

Oddly, this correction doesn't appear until the middle of the article:

Clarification: The RenderMan/Azure demo shown was a proof of concept.

I would think it's the opposite: for a small-to-medium shop it makes all kinds of sense to concentrate on your core (design, animation, client development) and just rent "rendering as a service".

a) If you have a small headcount, a dedicated server wrangler's salary would be better used to pay for a person with a more product-oriented profile. That's what makes the difference between you and your competition: you aren't writing your own renderers anyway.

b) When maintaining your own serverfarm it can be difficult for you to have the jobs pipeline full at all times, and you can either have a lot of spare capacity sitting around between jobs, or need more horsepower during peaks.

c) This also allows small-to-medium shops to tackle problems bigger than they could otherwise from a pure cashflow point of view. If you are renting rendering-as-a-service, your clients are paying for the hardware their jobs need, no need to invest, amortize, etc. Just pay an invoice coming in and an cash an invoice going out.

It seems to me that these are exactly the kind of problems SaaS is designed to solve, and that small-to-medium shops can benefit from this solution more than big studios who can:

a) amortize their server wranglers over bigger installations, so their sysadmin/creative ratio is lower.

b) keep the rendering farm working efficiently, or even rent it out if they have lulls in work.

c) afford big financial investments.