This happens all the time. Given enough qualifiers, any movie is the "first" of its kind.
"This is the first computer animated movie"
"This is the first computer animated movie with photoreal humans"
"This is the first computer animated movie rendered with global illumination"
"This is the first computer animated movie rendered with global illumination, on a render farm of Linux servers"
"This is the first computer animated movie where the main character is green"
"This is the first computer animated movie where the main character is green and one of the characters is a cat"
It gets silly after a while. At some point you have to ask "is the movie any good?"
j
Re:I had this idea a long time ago :)
on
Rendering Shrek@Home?
·
· Score: 2, Interesting
This is correct. One of our main concerns when deciding how to store data, or when to store vs regenerate on the fly data for a frame is network bandwidth.
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.
Note that Ken (the interviewed guy) said *Our user interface*. Using only features that Quake uses makes a lot of sense if you want to maximize your chances that everything will work if you change graphic cards.
Having the lighting program tell you "you are tied for the lead" every time you move a light is a bit of a pain, though:-)
j
Re:Water is easy to simulate!
on
Shrek 2 How-To
·
· Score: 5, Insightful
Simulating water is easy, if you don't care what the simulation will look like. I mean, if you are happy with whatever the output of a Navier-Stokes solver is, then fine, wait for the computer to finish and you're done.
In a film, however, there's usually a director, an art director and a visual effects supervisor telling you to please move that splash a bit to the right, and make it happen three frames later. Oh, and sometimes there's also a story that those people are trying to tell, and your water sim is one of the tools they are using, so the *need* that kind of control.
Then there's rendering. Is there any foam? Splashes? Do things around the water get wet? Can you make that foam not *darker*, but *less bright* please? (this is a real comment I got during dailies in Shrek 2).
So, simulating water is easy. Simulating water making it do what you want, and rendering it so it looks the way you want it to look is extremely hard.
Every time there's an online discussion about cg movies, tons of people are fast to jump on the bashing of either of the main players.
PDI/DreamWorks vs Pixar, Ford vs Chevy, Pepsi vs Coke. Come on guys, understand that these are companies that make products with the intention you will buy them. That "customer faithfulness" rings silly in my mind, given that after all, we are the consumers and in general have little interest on the well being of those companies.
For the record, the cg industry is a small one, and there's a lot of coming and going of people. I've been at PDI for more than seven years, and thus know tons of people working here who used to be at Pixar, and tons of people at Pixar who worked here and are my friends, and the same could be said about any of the other major cg companies. There's no inherent difference between the talent of people in one place or the other.
j
Re:State of the art?
on
Shrek 2 How-To
·
· Score: 4, Insightful
Having been very involved in it, I shouldn't comment on people's perceptions of Shrek being a "half assed effort". But if you want to see what technologies and techniques were developed and used for Shrek 2, a good source will be the quite many Sketches to be presented at SIGGRAPH in LA in August. Check the SIGGRAPH site for a list (I don't think the sketches list is online yet though)
Yes, we rewrote an entire renderer:) We also use propietary software to do layout and animate characters, and our effects are about 60% propietary as well.
PDI has been around since the early 80s, when commercial software was not really an option. Over time, we've amassed both a core of pretty cool technology and an r&d group to put it together. Face it, any project the size of Shrek will require lots of ad hoc software, and having total control over it is definitely an advantage.
As other posters already said, it is a published paper, so it's out there already.
BTW, here's the technique. It's really simple actually:
Before rendering each frame:
- sample the object with points on its surface;
- solve the illumination of each sample point (to get the amount of light falling on each)
- save this data somewhere.
During rendering:
- For every point being rendered, look for nearby samples (several techniques could be used for this, the paper used an octree structure, but my first implementation used just a flat 3d bucket sort of the samples)
- Average the values of all nearby samples, with some kind of falloff (the paper does the right physical think, using an exponential function--my first implementation used a cubic function that approximated the exponential while falling off to zero at a finite distance)
The value you get approximates the amount of scattered light. That's all there is to our 2002 paper, really. The rest is math, justification and embellishments. There is a lot more to rendering skin than subsurface scattering though, like layering and good texture maps, plus usability if you have tens of artists using the tools.
And yes, the technique could be patented, but it would very much suck if we had done that. My implementation is closed, since I wrote it at PDI on our propietary renderer, but as you see, it's simple to implement anyway.
Henrik published the diffuse approximation on 2001, and in 2002, he and I published a ~100x improvement on that, which actually has little to do with it except mathematically... This is the technique that is being used in several production houses nowadays, and why Cristophe among others got the special achievement award (not OscarTM). PDI/DreamWorks, the place I work for, was left out because our first movie using the technique, Shrek 2, was not out at the time:-(
This image of Fiona's mouth was in the back cover of the 2002 SIGGRAPH proceedings:
Slashdot Mirror
"This is the first computer animated movie"
"This is the first computer animated movie with photoreal humans"
"This is the first computer animated movie rendered with global illumination"
"This is the first computer animated movie rendered with global illumination, on a render farm of Linux servers"
"This is the first computer animated movie where the main character is green"
"This is the first computer animated movie where the main character is green and one of the characters is a cat"
It gets silly after a while. At some point you have to ask "is the movie any good?"
j
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
Having the lighting program tell you "you are tied for the lead" every time you move a light is a bit of a pain, though :-)
j
In a film, however, there's usually a director, an art director and a visual effects supervisor telling you to please move that splash a bit to the right, and make it happen three frames later. Oh, and sometimes there's also a story that those people are trying to tell, and your water sim is one of the tools they are using, so the *need* that kind of control.
Then there's rendering. Is there any foam? Splashes? Do things around the water get wet? Can you make that foam not *darker*, but *less bright* please? (this is a real comment I got during dailies in Shrek 2).
So, simulating water is easy. Simulating water making it do what you want, and rendering it so it looks the way you want it to look is extremely hard.
j
PDI/DreamWorks vs Pixar, Ford vs Chevy, Pepsi vs Coke. Come on guys, understand that these are companies that make products with the intention you will buy them. That "customer faithfulness" rings silly in my mind, given that after all, we are the consumers and in general have little interest on the well being of those companies.
For the record, the cg industry is a small one, and there's a lot of coming and going of people. I've been at PDI for more than seven years, and thus know tons of people working here who used to be at Pixar, and tons of people at Pixar who worked here and are my friends, and the same could be said about any of the other major cg companies. There's no inherent difference between the talent of people in one place or the other.
j
j
PDI has been around since the early 80s, when commercial software was not really an option. Over time, we've amassed both a core of pretty cool technology and an r&d group to put it together. Face it, any project the size of Shrek will require lots of ad hoc software, and having total control over it is definitely an advantage.
j
BTW, here's the technique. It's really simple actually:
Before rendering each frame:
- sample the object with points on its surface;
- solve the illumination of each sample point (to get the amount of light falling on each)
- save this data somewhere.
During rendering:
- For every point being rendered, look for nearby samples (several techniques could be used for this, the paper used an octree structure, but my first implementation used just a flat 3d bucket sort of the samples)
- Average the values of all nearby samples, with some kind of falloff (the paper does the right physical think, using an exponential function--my first implementation used a cubic function that approximated the exponential while falling off to zero at a finite distance)
The value you get approximates the amount of scattered light. That's all there is to our 2002 paper, really. The rest is math, justification and embellishments. There is a lot more to rendering skin than subsurface scattering though, like layering and good texture maps, plus usability if you have tens of artists using the tools.
And yes, the technique could be patented, but it would very much suck if we had done that. My implementation is closed, since I wrote it at PDI on our propietary renderer, but as you see, it's simple to implement anyway.
Juan Buhler
(coauthored Henrik's 2002 paper)
Henrik published the diffuse approximation on 2001, and in 2002, he and I published a ~100x improvement on that, which actually has little to do with it except mathematically... This is the technique that is being used in several production houses nowadays, and why Cristophe among others got the special achievement award (not OscarTM). PDI/DreamWorks, the place I work for, was left out because our first movie using the technique, Shrek 2, was not out at the time :-(
This image of Fiona's mouth was in the back cover of the 2002 SIGGRAPH proceedings:
Fiona
j