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?
I wonder if that would be considered pirating by the MPAA. Smart people out there would figure out a way to "download" the movie from the frame generated. Then there would be no reason to see it in the theater. Just playing the devils advocate. Personally I think it would be REALLY cool :)
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.
How would the legal aspect work out? Seems like you'd have to sign a fairly strict license saying the movie studio still owns what your computer rendered, copyright, etc.
Very cool idea nonetheless.
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.
Mine! Mine! You filthy thieves!! All you want is to get your hands on frames from MY movie and then you'll mix it with porn, put it on P2P networks and use the proceeds to fund terrorism!
It's my movie! MINE! You want a screensaver -- well, pay in DOLLARS for it, you dirty pirate (* by clicking here you agree that your credit card will be automatically charged $0.99 each time your screensaver kicks in)! And note that you are licensed to use MINE screensaver on just machine by just one user and that our DRM system will make sure of that (* fingerprint reader, purchased separately required for system activation and use)!
Thieves, all of you are thieves! Hah, give them movie frames to render... What, you think me stupid?
Kaa
Kaa's Law: In any sufficiently large group of people most are idiots.
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.
Despite the coolness of the SETI project, the major reason I support SETI and other scientific projects (e.g., protein folding@home) is that they are notoriously underfunded. SETI and the organization which operates folding@home (Stanford?) do not make profit, and at each step have to literally beg the government (usually the NSF) for more grants. This is especially true of SETI, which has become a pretty out-of-fashion program in funding circles. In short, the whole point of donating CPU cycles is to allow somebody access to computing power that it would not otherwise have. While I enjoy the Shrek movies just as much as the other guy, I'm not so philanthropic when it comes to a company that's capable of making $128 million in one weekend. Here's an analogy: you might donate clothing to the Salvation Army, but would you donate to Sak's Fifth Avenue? I think not -- I suspect many of you, like me, would rather support the little guy with no alternative.
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.
I agree with most of the comments so far about why the idea wouldn't work directly, but I'm more optimistic about the general idea. For example, there is a technique called "partial abstract interpretation". The idea is that given code and the input data, one can see what the code would do on the input data and then change the code to not accept any input and do the correct thing on that particular given input. If the company distributed code in this way, it would just be code and no data (so their artwork doesn't leak out), and the code would only work to generate one scene; it would be hard or impossible to uninterpret the code (so they doen't leak their proprietary rendering technology).
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
Depends on how you define "no real actors". "Real actors" were used for the voice work. If you ever played a video game where the voice acting was horrendous (about 80% of the time), then you know that good voice acting isn't that easy to come by. You also need talented animators to turn the 0's and 1's into emotion. In any case, Hollywood has always been more than just the actors, there's a whole production crew behind the picture.
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.
The movie industry, give you something like that for free? I doubt it, maybe if you paid them so they could render on your computer....
There is no replacement for displacement.
Rendering a movie is more than just handing PoVRAY a set of data and telling it to render. Distributed computing will not be able to handle it for a lot of reasons.
First off, what is rendered by the computer is not what you see on screen. There are perhaps a dozen object layers that are rendered individually and composited in the postproduction phase. So, for example, Shrek might exist on one layer, the donkey on another, the ground on a third, some foreground objects on a fourth, several layers of background objects on the fifth through tenth, et cetera.
Now, each object layer will also be split into several render layers, for color, shadows, specularity, reflectivity, transparency, and probably several others that I can't think of right now. It is not an exaggeration to say that a single frame of a completely CGI scene can be made up of upwards of fifty individual frames, all composited together in post.
Why is this done? First off because it's easier to edit and change one of these layers and re-render it, than to change and re-render the entire scene. If Shrek is too gruesomely gleaming, but Donkey is just fine, you just have to edit Shrek's specular layer. This is easilly done in any professional postproduction software package. Alternatively, if it's completely wrong, you just have to re-render that specific layer -- saves a LOT of time! Some post tools are extremely powerful, which makes rendering to object/render layers very appealing.
Now, while you could conceivably do Shrek@Home, you would need a fairly large render program -- and you're already distributing a very powerful program, which the people who wrote it would be very uncomfortable doing. Secondly, the processing power in even high-end PCs is going to be jack compared to what they have in render farms, and they have a lot more of those computers besides. Rendering is very processor-intensive, too. It's a complex mathematical process that can take hours. Many computers will chug along at 99% load on the processor because they HAVE to.
Add to the fact the stake in the heart of this idea: that the producers want reliability first and formost. An in-house render farm, or even renting time at a farm (an idea I've sometimes played with) that signs and seals and delivers is going to be reliable and dependable or they will know exactly whose head needs to roll. If you start having half the internet rendering the million or so frames of your blockbuster, who do you hold accountable when the deadline comes and you're short 1000 various random frames?
"I am an Adept of Tantric VAX."
first we would render parts of the movie on our own pc's and if we would like to go to see the movie in the theatres we'd have to pay 6.5 euro for something i helped create.
next i won't be able to play the dvd legaly (which i had to pay for again) on my linux box.
can't wait to start...
On a long enough timeline, the survival rate for everyone drops to zero.
I work in the industry and the need for large render farms is going away soon. Workstation level video cards are capible of rendering scenes at or near real time. The big problem has been software support. The first commercial product to do this is already on the market. It's called Gelato. It comes from NVidia and works with most of their workstation level cards. It'll take a few years for the new technology to settle and support all the animation packages and operating systems but eventually everyone will have some form of card support for rendering. Each artist will simply render the final scene at their workstation. The two biggest technical problems, rendering and storage, are rapidly becoming nonissues.