Slashdot Mirror


ILM's Datacenter

kylegordon writes "CGW has inside scoop on Industrial Light and Magic's facilities after they moved from San Rafeal to San Franciscos Presidio. With 3000 disks, it can shift 170Tb to 5000 rendernodes over 10GbE and 1GbE network links. It's an impressive system, for impressive films."

3 of 156 comments (clear)

  1. Hurray for Movie Technology! by eldavojohn · · Score: 5, Funny
    With 3000 disks, it can shift 170Tb to 5000 rendernodes over 10GbE and 1GbE network links. It's an impressive system, for impressive films.
    Unfortunately, all that storage can't provide decent acting, quality humor or plot lines without holes for their movies.

    I bet I could make a graph that represents how the quality of movies is characteristically inversely proportionate to the amount of CGI effects in them. Oftentimes, eye candy is used to shroud the plot and mask the bad acting/directing. American audiences especially just go looking for explosion sequences and CGI in the annual summer action flick hunt. We often fear a movie that might prove to be too cerebral and that pretty much disgusts me. Way to reinforce bad movies that are only good for one viewing with volume set to 'loud' and TV set to 'huge.'

    ILM is responsible for making movies like The Mask (of which there are seven films) and characters like Jar-Jar Binks possible. Be sure to thank them for that.
    --
    My work here is dung.
  2. Liar by Kombat · · Score: 4, Insightful

    I ALWAYS notice CGI.

    No you don't. You think you do, but you don't. When you do notice it, you point it out and say to yourself, "that was so obvious, CGI sucks." But when you don't notice it, you don't realize that what you're looking at is CGI. You think it's real. You think the man really has had his legs amputated ("Forrest Gump") or Arnie really did jump his motorcycle off a 15 foot ramp ("Terminator 2"). CGI is used all over the place in movies now, not just for the big explosions that still may not look 100% convincing (however, it's much better than stop-motion animation).

    --
    Like woodworking? Build your own picture frames.
  3. Re:Nice network by flaming-opus · · Score: 5, Interesting

    That's a funny question because I used to work at ILM's (San rafael, much less shiny) lab, benchmarking raids, including the first version of the IBM shark. At that time we came to the conclussion that the IBM raid was reliable, and reasonably fast, but the price was so far out of line, that it wasn't a real contender.

    The shark, and many of the high-end raids, are really designed around transaction oriented applications (databases). ILM's application are classic video codes, which work better on a classic raid5, than they do on the data-sprinkler style raids like the shark, eva, clariion, etc. Netapp makes pretty decent storage boxes, and they're highly configurable, so I'm sure they have them fine tuned to the apps' preffered i/o size.

    Furthermore, the nas/san has more to do with the spinaker software than the raid of choice. Back when I worked there, ILM was testing cluster sollutions, but the renderfarm was a bunch of sgi origins. The storage was hung off of a couple of 8-way irix boxes, and pushed around with NFS. Since then they've upped their compute capacity by a factor of 30, there's no way they'd be able to do all that I/O with NFS to a couple of big servers. The san setup lets them distribute the NFS load to a large number of servers, all sharing access to the storage on a san. A lot of other cluster filesystems allow this too.

    From the benchmarking I've done of these types of storage clusters, you don't get the same single stream performance as you do from a big-iron server setup, but the aggregate across a large number of nodes is pretty good. Managing the mess, and reliability can be problematic. I've never used spinaker, but I've used almost all the other products in this space, and they're all in the "pretty good" category. My current favorite is apple's xsan, because it is really inexpensive, and so is the hardware.