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.
We could have entire CVS trees of movies!
Don't like how Matrix Revolutions ended? Just load up the "Smith kills us all" branch and choose your own adventure!
<insert witty linux comment here>
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.
Users gladly contribute their spare CPU cycles to fold proteins for a non-commercial purpose, or help a non-profit organization seek out alien life. These are tasks affecting all of mankind.
Giving away CPU cycles so that a multi-million dollar company can improve its product is a wholly different thing.
Actually, from what I know of Pixar's renderer, it actually wouldn't be that difficult to do something like this. For starters, Renderman can be purchased. Secondly, it uses technology that was formerly Open Source (Blue Moon Render Tools) so it isn't like it is totally proprietary. RIB files are pretty big though, so the data would become a problem. I think you could send just deltas though from the last frame rendered if you were tracking, RIB is just a text file, so it wouldn't even be too hard. Renderman, if I recall correctly, is a bucket renderer, which means that each frame is subdivided into many subframes which are rendered and then assembled. It would be possible to only send the subframes to the distributed network and do the frame assembly back at the studio. This would mean your machine might render Buzz Lightyears elbow, but you're not going to get to see a whole lot of the scene. Trying to hunt down all the little chunks of one frame and then assemble the frames into movies would be even more difficult for a pirate. Now, the shders that Pixar uses might be a bit of a problem for them to release, but then again, by the time the movie goes into final rendering, the technology in the film is a few years old, so it isn't like they'd lose a lot of ground. Besides, a lot of these techniques are either implementations of SIGGRAPH papers, or are presented in papers at SIGGRAPH after they are created. I think the only MAJOR concern is the tampering with the output. I don't think there is anyway to safeguard that (you could encrypt it, but that still leaves plenty of holes in the system, you could always hack the output buffer in memory, etc.) The main problem of course being that the only way to see if a frame wasn't tampered with would be to compare it to a render of the frame....and well, then what is the point....
Great, maybe for saving some effects company from shelling out for a few more $10K graphics servers with which they will make the next $150M movie, perhaps I can loan them a few CPU cycles and they'll cut down my move ticket cost from $10 to $9.75.
It's hard enough to solve issues regarding parallel processing of images in a clustered environment they can control. Why put that process in an environment they can't control? It's not like movie studios can't afford a computer cluster. That's a small cost compared to the cost of hiring someone to write the distributed software they use.
From what I've read, Seti@Home works well because users heavily process a small amount of data and return a small solution. If we were processing frames, it would require the user to take in large amounts of data and return even larger results.
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.
You might be the unfortunate soul that renders a movie spoiler as you watch the images coalesce on your screen ...
Because the production of a blockbuster movie tends to be kept a secret up until near the premier. distributed computing provides little to no security.
There's no way a studio could send a scene's model to a compute node encrypted, process it encrypted, store the interim image encrypted, then send the whole mess back encrypted. At some point in processing the information must be in plain computer processable formats.
What that boils down to is that a competing studio could sign up hundreds of compute nodes and get a preview of the story line and animation. Anyone who could gather enough images could piece together clips from the film and release them in full digital format. Imagine a nefarious group of nodes all collecting the images they generate and later piecing them all together in to perfect digital non-DRMed copy of the movie; before release and before the DVD is available.
Hollywood can't stand the idea of people copying DVDs to the internet, could you imagine what they'd think of full film resolution copies of their films floating around? The heads bits: on the walls.
No... this is just a stupid suggestion from the point of view of the studios. At least until there's and OS is produced where a user it prohibited access to certain portions of RAM, and can't intercept the network traffic to/from the box.
Article X: The powers not delegated... by the Constitution...are reserved...to the people
This is not just tracing all of the rays in the scene.
Bruce
Bruce Perens.
While I'd love to render Halle Barry topless - I'm not sure I'd be using a computer.
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.
I wouldnt do it for the same reason I refuse to buy clothes with logos on them that advertise the maker of those clothes, or some other form of advertisement.
If someone wants me to wear such advertisement-enhanced clothes, they should pay me for the priviledge.
Same with computer cycles. I pay the electricity. If they plan on making money from the product of the cycles I give them, they should pay me.
However, I have no problem giving away free computer cycles to non-profit scientific endeavors.
I could see this for an indie project, but no way for a feature film. The reason why, I think, is because that in order for a computer to start rendering a CGI frame, it must have several things: Geometry, textures, lighting algorithms, and any procedurals needed to make things like fur, hair, realistic water effects, etc. Now, if I were PDI, or any company that has spent millions in R&D in creating these things, do you think I would want this info on Joe Schmoe's computer just waiting to be opened up and reverse engineered? I don't think so.
-R
There is a great article about how ILM does their rendering. It was a cover story in Linux Journal magazine.
http://www.linuxjournal.com/article.php?sid=6783
People have been saying that even if the studio didn't care about the security issues, there are bandwidth issues that would keep this from really working. There are a few quotes in the article that confirm this: all the rendering machines make a sort of denial-of-service attack on their NFS servers, for example. And the article talks about their VPN, which they call the ILM Conduit; it sends everything double-encrypted with Blowfish. They really are worried about security.
The coolest thing, to me, is that ILM has rolled out Linux all the way across their organization; people run Linux on their desktop computers. When people go home at night, their computers get added to the render farm!
steveha
lf(1): it's like ls(1) but sorts filenames by extension, tersely
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).
The sole reason this will not work using current internet infrastructure is bandwidth.
In the making of Final Fantasy, it took longer to send the information to the nodes than it took the nodes to process it. That is with dedicated gigabit networking.
Sigs? We don't need no stinking sigs!
The only way I see for this to be feasible is if each user was only rendering a tiny segment of each frame. I don't know if this is technically possible, but, it would reduce the massive bandwidth needs to a more SETI like level.
Secondly: Users cannot see what they have rendered. This is a given, as has been pointed out a thousand times already, this is insane from a security and PR standpoint. INSTEAD, simply let users who participate on a regular basis have access to a private forum, developer blogs, and grant them access to the official PR material slightly before it gets published. It's less cool, sure, but it could work.
If the resulting product from the distributed computing were public property, or for the public good-- then I could see it.
But to offload all the costly/time-consuming work and THEN let them sell it back to you 4 or 5 times (Theater, Pay-Per-View, DVD Rental/purchase) along with all the marketing tie-ins doesn't seem to make sense (to the consumer, that is. For them it's great, less equipment overhead and quicker turn-around.)
If you think that's a good idea, I've got some swampland I can sell you.
This type of thing makes absolute sense for things that might not otherwise get funding and don't derive a profit (SETI@home, Folding@home, etc.).
If you want to get paid next to nothing animating scenes for a giant studios next big movie, get a job at some asian animation house.
Remember, Dreamworks and Pixar are companies trying to produce a product that they will sell. Every day it takes to build that product is money down the drain. They do not want their development time-line to depend on how many of their "fans" currently have their machines on or what their Internet connection speed is or even how crappy of a computer they have and what other tasks it is running. Seems to me trying to plan an expensive project like a movie with that type of model would be a nightmare.
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
Now you can subsidize the movie industry with your computer and electricity.
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.
Imagine if they had these inside their computers too.
http://www.missionfaces.com/
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.
When making CG films like Shrek (or any CG done in great detail), each scene is not rendered wholesale, but rather done by layers. So, the backgroud might be rendered by this set of computers by this part of the farm, while another renders lighting, etc., or that they're rendered in different sessions. This adds another issue to the problems for distributed movie rendering -- compositing. A compositor needs all the different layers from a particular scene to tweak and play with, of course, so the compositor would have to wait for the animators to finish a scene, (nevermind the data needed for rendering) send out all the work units needed to render all the layers, then wait for alllllll the WU to complete, quality-check all the WU, and then start composition work. And then it's entirely possible that a compositor might ask for a layer to be re-rendered because it just didn't work out and changes were needed to make the scene look better. Rendering is NOT the final step to complex CG animation, so even if distributed computing can somehow work, it would only hurt the production team.
- - - - - Bringing the joy of Pedo Bear everywhere.
Now, it might make sense to go to some rental service that can set up the licenses and servers and just charges per CPU hour, license hour, and MB on the server. It wouldn't be a small thing to set up, though, and it would be a professional service with strict NDAs.
For Shrek, and according to Dan Wexler's statistics at http://www.flarg.com/Graphics/ShrekRenderfarm.html , on average each frame took 2GB of data. I'm not sure and won't bother to find out how much we used on Shrek 2, but of course chances are the figures are even bigger.
This alone would make it impractical, without even taking into account all the IP and copyright issues.
j
If you send the same input to three different IP addresses (extra-paranoid: use three different top-level IP blocks) and get the same result back, you can be reasonably certain that the result is valid.
Actually, just double. First use "Comparison Mode". If the two come back different, resolve it by switching to "voting mode", doing a third frame at a third site and seeing which it agrees with. (If all three disagree you've got a systematic problem and you need to debug the whole project.)
If there are -any- discrepancies in the images, assume that one (or more) was improperly rendered, discard all three, and try again with three new addresses.
A disagreement proves that at least one of your sites had a problem. But (unless there's some non-randomness to your selection of the three sites) the fact that ONE of your first set had a problem does NOT mean that the OTHER sites in your first set are any more likely to have misrendered than the new sites. So there's no reason to throw away the results from your first set. Just use the additional site(s) to select which one of your first set was wrong.
If a significant fraction of your sites are compromised to make identical misrenderings, you still don't want to throw away your original set. Keeping them all and going to 5, 7, 9, etc gets you closer to the likelyhood of the right answer, while discarding them and repeating a 3 site run with new sites gives you a greater probability of accepting the wrong answer.
= = = =
But all redundant systems fail if you have a systematic problem that may affect more than half of your potential samples. For instance: A virus infection that causes a systematic corruption of the rendering process (i.e. changing the texture map so the pants are transparent or carry an image of genitilia). If more than half render wrong than right, more redundancy makes you accept more wrong frames.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
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?
help finding a small pox vaccine than helping the already way-too-rich entertainment industry.
The purpose of life is to find the purpose of life.
I work in a visual effects/video production shop as system administrator, so i know firsthand how much data is required to do a simple animated spot/visual effects shot. An average 30 second spot for TV (which is about 1/4th the resolution of film) takes around 200 to 400 GB of data. Our network is all GigE based, with Terabytes of Fibre Channel storage. Even with all the power available to us (Mac G5's and Intel Xeon based rendering systems) it takes forever to pump out the frames for a spot. In short theres no way people can crunch this kind of workload without having to download gigs of information first. With tight project deadline s and tons of protected intellectual property at stake this kind of work is best kept in house. you can check out our web site here
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.
will deal with that. You may seen a generic screensaver, but I doubt that a company would risk leaking their movie. However, it is possible to perform certain calculations (such as addition and multiplication) in a way such that the clients in this scenario would work on encrypted values.
The calculations are done in encrypted values and returned as such. The host can then decrypt the result.
This sounds pretty amazing but consider addition as a starter: The host uses a one-time-pad for each number and XORs them. The client adds the encrypted numbers. When you add the numbers, the host only needs to XOR all the keys on the result and gets the true result! The client, though, knows NOTHING about the true values (the protocol is information theoretically secure), as the XOR turns them into "signal noise".
I imagine, though, that the effort of implementing this probably outweighs the benefits for a project like rendering a movie. But for truly mission-critical data, it may be worth it...
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'd gladly trade some spare CPU time in exchange for the coolness of seeing a few frames of Shrek 3 rendered on my screensaver!"
I wouldn't. What a waste.
The man who trades freedom for security does not deserve nor will he ever receive either. - Benjamin Franklin
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.
Allow movie companies access to the virtual farm at a rate of 1 cent per frame or something like that. Then the person who renders the frame or who has contributed X number of render units has the option to have the micropayments sent to a charity, open source project or site of their choosing.