Slashdot Mirror
Rendering Shrek@Home?
JimCricket writes "There's an interesting piece at Download Aborted about using distributed computing (a la SETI@Home, Grid.org, etc.) in the film industry. With the recent release of Shrek 2, which required a massive amount of CPU time to complete, one must wonder why the film industry doesn't solicit help from their fans. I'd gladly trade some spare CPU time in exchange for the coolness of seeing a few frames of Shrek 3 rendered on my screensaver!"
Security issues would be a concern I'm sure. There's plenty of hackers who'd see no harm in, for example, extracting a number of images from around the world and sticthing a trailer, etc. And of course, rendering is a "trial-and-error" process - would they want people to have access to broken scenes? Or deleted scenes? Speculation would seriously dampen their ability to control marketing and release info. On the technical side, farms are reliable and predictable. Who can figure out how many fans will keep their computers up tonight for the critical preview tomorrow? What about the decline of interest after first little while? Distributed computing of this sort isn't well suited for commercial projects with fixed schedules. Not that I don't think it'd be COOL... I just don't think it'll happen :-/
- To err is human; but to really screw up, you need a computer
Don't animators already insert single-frame porn, etc into these things?
Can you imagine how quickly the client software would get hacked, and how crappy the movie resulting from nothing but single-frame porn shots would be, especially to photosensitive epileptics?
Easy: Pixar and Dreamworks have both developped highly proprietary rendering technology. They're not about to just give copies to everyone who wants one. Even if the renderer itself weren't reverse-engineered, which isn't beyond the realm of possibility, it would likely be far easier to decipher the protocol used and voila, a functioning copy of [Pixar|Dreamworks]'s renderer.
Lobotomizing it to the point where this wouldn't be useful would probably make it useless for distributing the workload as well.
I'll set up a cluster of old Pentium 200MMX's and put 128MB of ram on them... they'll be rockin! When people see my garage full of cables and ancient hardware and ask "WTF are you doing with all this crap?" I'll be able to say "rendering Shrek 3".
Distributed computing for rendering a movie? I think they have enough hardware problems without getting the worm infected masses into the mix.
Nobodies Prefect
Tidbits for Techs Technology Blog
The film industry can afford it so...
Why would they want to do the distributed??? They are using 10Gbs etho and blow your mind away servers to render at amazingly high rates. Probubally several times faster than something like the SETI network could imagine.
And hell, those sysadmins have the most owerful systems in the world. Who would give that up? They even get whole new systems every couple years.
Evolution or ID?
I beg to differ. I suspect that the reason why no one's ever bothered suggesting this is that the amount of bandwidth required to download the frame data and upload the rendered frame are prohibitively large. Besides that, the licensing costs for the rendering technology would be enormous, and what film company would want to freely distribute all of the models, textures, and animation that they spent dozens of man-years working on?
Nice to see you can advertise your NEW BLOG on slashdot...
how much did it cost?
Films and other large productions are tightly scheduled, with costs against these schedules mapped out months in advance. I can't think of a producer who would count on an essentially unschedulable resource as a vital part of their production pipeline, regardless of its economy.
That said, I could totally see a use for a 'render pool' catering to independent filmmakers, students, and nonprofits for whom cheap is more important than timely.
Marc Siry || interactive media professional, motorcycle enthusiast ||
The problem with trying to help render frames is that your system needs to have the data to do it (3D objects, textures, etc.)- not to mention the renderer. Companies wouldn't take kindly to sending off their IP data (esp. custom 3D models/textures/shaders) to the masses to be hacked. Having people get a hold of the "official" Shrek models and textures for example would be a bad thing.
Do you really want the MPAA to run programs on your computer?
No one has seen what you have seen, and until that happens, we're all going to think that you're nuts. - Jack O'Neil
But they could tell everyone they were, just have a screen saver that pegs the CPU, tells you that you've rendered X frames, and displays a cool screensaver from the movie! :)
Great PR, no loss of technology, lots of pissed off fans, once they realize the truth!
Agile Artisans
I wonder if you could get a section of the frame(s) you (helped) to render...
/.ers would combine their powers and probubally have a lot of the movie weeks before it was released.
Evolution or ID?
The main reason they don't employ this technique is that their own 'render-farms' are a known quantity; they can, with reasonable accuracy, calculate how long a given scene will take to render, whereas with public distributed computing this calculation is not possible.
There are many variables in distributed public computing such as:
*Different CPU capabilities.
*Different OS capabilities
*High/Low use Systems
*People's 'uptime'
*Users leaving the project before its completion etc.
Another risk is that another movie-house could start a production which everyone sees as 'cooler' and your entire userbase decides to up-sticks and render for them instead.
Ripping an new rectum in the fabric of spacetime.
How cool would it be to see them allocate THEIR distributed system to projects like SETI, etc. Even though I'm sure there are other projects being worked on, one would imagine the system is pretty dormant after a release.
Both studios are using Renderman compliant renderers, so that's not the issue.
And there's no reason that any one machine has to render an entire image file. You could have any node build N number of scanlines and send the packet back home.
The risk would be someone running a port monitor on the return address, and re-assembling digital image files.
...data, nay terabytes of data, can go into a single frame in a movie? You might be able to farm out stuff like some fragments of procedurally rendered smoke that rely on computing noise functions repeatedly, rather than accessing a scene database, but in general this is completely impractical. If visual effects houses wish to share data the easiest thing to do is FedEx a bunch of hard drives. So unless Shrek@Home includes some kind of hard drive exchange program it ain't gonna work!
Doesn't it make you feel good to know that our freedoms are protected by politicans, lawyers and journalists.
At Pixar, distributed rendering, even within the same building, was sometimes I/O bound rather than compute
Bruce Perens.
Only the most high end of machines could even consider attempting to render even one layer of a frame for this kind of animation. We're talking systems with 2-4GB of RAM as a minimum (preferably 4+) and the scene files/textures would weigh in the tens to thousands of megabytes that must be downloaded for each scene. Think uncompressed TIFF or TARGA texture files that might be 5000x5000 at 40 bits/pixel.
:)
Even on high end machines they often do not render a full frame, but a layer of a frame which is then composited with other layers into the full frame. Why? Many reasons but one of them is that even the high end machines don't have enough RAM and the render would take too long (the machine would need to swap).
So aside from the issues of fans returning bogus data, or extracting highly proprietary information out of the client as other threads have mentioned, this would be a real show stopper. Breaking the problem into small enough pieces to be handled by joe-blow's computer would be prohibitive and require tons of calculations to figure out which pieces of textures are actually required for a given piece of rendering etc. It would probably require a compute farm just to manage it!
Rendering is also a lot more complex than you might think, there are render wranglers who manage the rendering queues and look at the outputs... many renders may require specific versions of the rendering software, so a frame that rendered with 2.7.2.1 won't render anymore without errors with 2.7.2.2... so many copies of the software are managed in parallel with the wranglers helping to clean up the errors. How would you manage this in a distributed client environment?
Furthermore most of the proprietary rendering apps are certified against VERY specific platforms, eg. one specific kernel version and build level, specific versions of shared libraries etc.
Long and short is there's a reason why movies cost millions.
The last film I worked on, we had anywhere from 800MB to 12GB of data per frame that the renderer had to have. I am talking about compressed renderman rib archives, textures, normal maps, displacements, shadow and other maps.
The data was mostly generated at render time for things like hair and shadow maps, but if it was being distributed, there is no way to do that - they would be transferred beforehand.
Also, there are always many terabytes of data generated by the renderers for each render layer, for diffuse color, specular color, etc.
It is just not feasible to transfer all that data around, and its not like bittorrent or other p2p systems will help much with that since each frame would most likely only be rendered by a few people (for verification).
Also, the model geometry and shaders (and somtimes textures) are closely guarded secrets... In short, if a major film were ever to do somthing like this, everyone participating would need huge (> 100mbit) bandwidth and a LOT of disk space and also be under very tight NDAs.
This is not just tracing all of the rays in the scene.
Bruce
Bruce Perens.
Awhile ago, John Lasseter of Pixar was in some promotional documentary for one of their films. He claimed that when they originally created their short film with the desklamp, render times were around 7 hours per frame.
He said that for Finding Nemo today, render times were about...7 hours per frame.
More machines and faster processors let you cram much more detail and technology into the same package. Working in commercial advertising, digital editing and graphic workstations are fantastic and powerful...but their advantage isn't speed. We spend the same amount of time making a commercial as 10 years ago...but now we make 7 versions and change it 30-some times along the way. Power gives you the ability to change your mind....and that's a creative force which people gladly pay for.
-Barkeep, a draft of your most hazardous brew, for the world is slowly stepping into focus, and I don't like what I see.
Shrek2 just shattered all kinds of records [...] And there are no real actors.
You do still need voice actors. With an animated feature, a really good voice actor can really add to the experience.
And you still need to make the character models move in realistic ways. So you need motion capture actors, or else truly skilled "puppeteers" to animate the models.
All that said, I actually agree with you. Take a look at Killer Bean 2: The Party by Jeff Lew. One guy made this, using his computer at his home. I think it's really cool that people can just make movies now with only a tiny budget.
steveha
lf(1): it's like ls(1) but sorts filenames by extension, tersely
How would you ever reproduce this on a distributed network of limited bandwidth home PC's ? Here's some LOTR rendering stats from Wired.com - [http://www.wired.com/wired/archive/11.12/play.htm l?pg=2]
... The Return of the King, which opens in theaters December 17, will feature almost 50 percent more f/x shots than The Two Towers and will be composed of more data than the first two movies combined. Churning out scenes like the destruction of Barad-dûr and the Battle of Pelennor Fields (with thousands of bloodthirsty CG Orcs) took 3,200 processors running at teraflop speeds through 10-gig pipes - that's one epic renderwall. What else went into making Frodo's quest look so good? By Weta's account, more than you might think.
WETA BY THE NUMBERS
HUMANPOWER
IT staff: 35
Visual f/x staff: 420
HARDWARE
Equipment rooms: 5
Desktop computers: 600
Servers in renderwall: 1,600
Processors (total): 3,200
Processors added 10 weeks before movie wrapped: 1,000
Time it took to get additional processors up and running: 2 weeks
Network switches: 10
Speed of network: 10 gigabits (100 times faster than most)
Temperature of equipment rooms: 76 degrees
Fahrenheit Weight of air conditioners needed to maintain that temperature: 1/2 ton
STORAGE
Disk: 60 terabytes
Near online: 72 terabytes
Digital backup tape: 0.5 petabyte (equal to 50,000 DVDs)
OUTPUT
Number of f/x shots: 1,400
Minimum number of frames per shot: 240
Average time to render one frame: 2 hours
Longest time: 2 days
Total screen time of f/x shots: 2 hours
Total length of film: Rumored to be 3.5 hours
Production time: 9 months
in the details, although perhaps not in the final answer. I would be very surprised if the actual input data is anywhere near that huge - do you think someone (or some group of people) actually did enough work to generate that many bits (and that's not counting the order of magnitude greater work done on things that got thrown away)?
What is much more likely is that the grass, skin, hair, etc. is described by some relatively simple input parameters from which millions of polygons are generated. The "rendering" process almost certainly includes generating the polygons from raw input data and seeded random number generators through perlin noise distribution routines through fractal instantiation through spline generation through polys to a rendered frame as the final product.
However, much of that work would only have to be done once, then shots taken from different angles on the resulting textured polygon structure, whereas on a distributed architecture any info that isn't sent to your machine would have to be regenerated for your machine. Not to mention that memory requirements are likely to be pretty darn high.
From: http://www.aspenleaf.com/distributed/ap-art.html#i mp
The Internet Movie Project renders images for computer-animated movies. The project is an open-source collaboration of volunteers and is just for fun. It is still in the development phase, but you can volunteer to be a "render-farmer," to render images for test animation sequences. Anyone who can run the free POV-Ray ray-tracing program can join this project, although the supporting scripts and software needed for the project only work on the Windows and Linux platforms for now.
As someone who works in a digital studio, it's painful enough getting things rendered with every computer in the same room. Frames get dropped, mangled, lost. In addition, every machine needs to be at the same software revision, and you can't have conflicting apps running. Scattering the render boxes across the planet and having boxes that contain unknown software will only amplify the pain to the Nth degree.
Added to that are huge bandwith problems. In order to render a 2K image, you may need dozens of texture maps, some of which may be even larger than 2K because you zoom in or something -- meaning to get a 2K frame back, you're sending the render box probably 10-20 times that amount of data. With a nice gigabit internal network, that's not a huge problem, but shipping them down a DSL line is just not gonna happen.
Giving away CPU cycles so that a multi-million dollar company can improve its product is a wholly different thing.
People pay to wear shirt that advertise mult-million dollar companies. : (
-Colin
My big question is why would you rather donate to a large commercial organization well funded from it's previous Shreck flick -- rather than donate the cycles to a project like the IMP works themselves?
From first hand experience... this won't happen, not for a long long time, if at all.
We used thousands of processors to render. We had terabytes of storage. It is a large undertaking. Every single frame and element of the frame had to be tracked. It had to be qualified. If something didn't work, we had to diagnose the system and get it back up and running. This is something that is too large of budget for a home brew system to work.
With other distributed systems, there are some checks and balances on the data ran, a way to know if you are sending back somewhat good data. The only way you can tell with this is to visually inspect the end result. If a person has a system that returns a bad slice of a frame, you now have to recreate that slice and track it, because its possible the problem is in the code, in the data files or it was a one time glitch with the system. Not a fun thing to do for hundreds of remote systems that aren't similar.
Render time also varies. It can be 5 minutes to 12+ hours. If a job gets halted, you lose that data, and have to recreate it. This isn't like generating millions of keys. There isn't a second init time before turning out data. At a previous studio, we had scene load times of over 30 minutes before it even started rendering. That needs to be accounted for in how you split up frames. If you have 30 minutes to load (after 45 minutes to download the data) and only render for an hours worth, you are getting a heavy hit on over head.
There are just too many issues with this working in a current setup. Stick to crunching numbers.
-Tim
-I just work here... how am I supposed to know?
I believe I saw someone earlier mention how there can be terabytes of data go into a single frame of CGI film, and these days that can be pretty correct.
.rib file or similar type file for PDI's renderer will probably contain a few million polygons and/or a few hundred thousand control verticies for implicit surfaces such as nurbs and sub-Ds, which can be a lot of data (my scene files at work average 4-5 million polygons and are about 150 megs on average, saved in a binary file format). And, that doesn't include particles, procedurals, all the motion data so that proper motion blur can be calculated...
A
And then the textures... They do use lots of procedurals, but they also use lots of 16 bit per channel textures of 4000x4000 for face textures, or even higher. Some people are using tiles if 16 bit tiffs for displacement maps now that equate to like a 100,000x100,000 image for displacement maps, because the accuracy requirements for close up renders are so bloody high. That can be many many gigs of data there.
And, if you're raytracing like in Shrek 2, then you need to have as much of that data in RAM at once, or else render time spirals out of sensibility, unlike scanline renderman where swapping is easier, because the rays bouncing throughout the scene make scene divisions more difficult (but still possible).
I work with 4 gigs of RAM and we can just barely render 6 million polygons + a few 4k displacement maps all raytraced at once (in windows unfortunately). And, when we render sequences and stuff, we often almost kill our network because distributing all this data to just 20-30 rendernodes is pretty tough (and how would that scale to a big renderfarm with thousands of rendernodes...)
So, yeah, like everyone else is saying, bandwidth limitations and that people running the screen saver probably don't have the hardware and OS to really run 4+ gigs of RAM, this Shrek@home idea seems rather unlikely. It would be cool though, if it worked...
Hooray for my totally unoriginal post!
you cannot dodge the quad laser. jumping is useless.