Slashdot Mirror
Rent A Bit Of Weta Digital
An anonymous reader writes linking to this story at stuff.co.nz, excerpting: "Five hundred powerful computers used by Weta Digital to help create the special effects for the Lord of the Rings may be put up for hire.... The pizza-box sized IBM blade servers each incorporate dual 2.8 gigahertz Intel Xeon processors and 6 [gigabytes?] of memory." Update: 03/22 07:08 GMT by S : The linked story says 6 megabytes of memory, we don't believe 'em.
No he didn't.
The best I could find was this mirror of the FAQ. Since ProcessTree.com now belongs to a domain poacher, I'm guessing they never did find a paying client...
"BSD: Free as in speech. Linux: Free as in beer. Windows 10: Free as in herpes." --Man On Pink Corner in #52607549.
Well, initially 32-bit Intel chips could only address 4GB's, but recently we have crazy shit like PAE that allows up to 16GB RAM to be installed and addressed by the OS that supports it, but applications can still only use 4GB at a time.
"Backups are for wimps. Real men upload their data to an FTP site and have everyone else mirror it." -- Linus Torvalds
The IBM HS20 has 4 DIMM slots used in banks of 2. No reason to think 2x2GB and 2x1GB would not work.
Linux, FreeBSD or Windows 2000 AS would support PAE allowing an app to use close to 4GB, leaving 2 GB for OS kernel , so seems reasonable.
Ay one who doesent believe me check at crucial.com. I wont provide a URL but look for IBM, Bladecenter, HS20
Of course its a bit faster to access 16Gb rather than 64Gb and faster againt access 4Gb for some PAE reason.
Xeons only go up to 4 megs of cache and those were just recently released. At the time these were bought the max was 2 megs.
Check out http://www.worley.com/fprime.html
My part-time employer (when I'm not working for NASA/JPL) Maas Digital just bought a copy of the software... it utilizes stochastic methods to allow flexible real-time raytrace rendering (with good motion blur!)
It turns out that motion blur in 3D graphics is a very hard problem because it's essentially a high-dimensional integral, and it turns out the best method of doing generalized high-dimensional numerical integration is a stochastic algorithm (monte carlo method) so it's not surprising to me that it's a great way to do motion blurs.
My favorite aspect of stochastic methods is their ability to be continuously refined (for instance, in a video game, the longer you spent looking at an object, the better it would get etc, and the graphics performance would degrade very smoothly with changes in system load etc). It is also ideal for parallel processing, as it can be dynamically parallelized to completely heterogeneous computing nodes.
Dan and I agree that there's going to be a lot of stochastic algorithms in the future of computer graphics (though he is hopeful that analytical methods will eventually make a comeback, as they have better asymptotic performance).
Cheers,
Justin Wick
You obviously have never worked in CG. Many common, simple effects cannot be parallelized. For example, Maya's particle effects are notorious for their inability to be parallelized and run on render farms, if they use randomness (and most particle fx do use randomness in positioning). Those fx must be rendered sequentially on a single CPU. Each frame's particle positions are used to calculate the next frame's particle positions, they're all calculated at runtime.
You don't get it. They're going to throw away more money trying to rent the server farm than if they just send them to a toxic waste dump in China. Unless, of course they can get nutball otaku like you to buy the old blades at extortionate prices as your little trophy, just so you can say "hey dude we can host your pr0n website on a machine they used to make LOTR!"
It means "nerd, loser; a person who has nothing better to do with their life so they pass the time by watching anime, playing videogames, surfing the internet (otaku is also used to refer to a nerd/hacker/programmer)."
That's a very complex subject, but it boils down to this: there's no technical reason you can't precalculate all the particle positions over time, but that's not how they did it in Maya.
Let's say for example, you set a particle generator to run 60 frames, emitting smoke from a point, like from a cigarette tip. Smoke particles start emitting on frame 1, and continue on their path, particles persist through frame 60 as they drift upwards in a path influenced by random air currents. If you roll forward to frame 30 and render the last half only, you start all over with no smoke from the first 30 frames, it starts from scratch, they emit right from the tip in a new smoke trail, there's no history of past particle movement. So you'd get a huge discontinuity if you rendered the frames in batches.
As far as I can tell, the actual image rendering doesn't influence the positions of the particles. It's just that they're calculated sequentially as each frame is rendered. Yeah, it's a huge pain and there aren't many good workarounds. But that's what you have to work with in order to use the particle generators, which are hugely powerful. Its the worst possible method, except for everything else anyone's ever thought of.
Otaku translates as "fan", usually in a bad sense where you will do something bad for your life to enhance whatever you are a fan of.
Basically, a normal renderer will render the scene from the top down. A Stochastic raytracer like F-Prime renders by shooting random rays all over wherever-the-fuck. As you leave the algorithm running, the image starts to look better and better. The more CPU time is spent on the image, the more rays are traced, and the better everything is. But, if you only have a small amount of CPU time, you still get a rough idea of what the scene look like, rather than an exact idea of what the top thirs looks like. That's really rough. To understand the point about motion blur, it really would be best to understand multidimensional integrals.
A dynamics/particle cache takes care of this. It's right there on the menu - and in the docs. Try it sometime!