3 ms·
Brent and the team at Disney Feature Animation have always pushed complexity like crazy. Most people keep telling them to just think procedurally or reuse elem
by boulos 12y ago
Brent and the team at Disney Feature Animation have always pushed complexity like crazy. Most people keep telling them to just think procedurally or reuse elements, but Brent prefers to let the artists do whatever they want and the system should handle it. Since cores are cheaper than humans this is a good long-term tradeoff, but YMMV since very few studios would bother doing so much explicit detail (as opposed to procedurally tweaked variations).
- davvid 12y agoAn interesting metric is that the San Fransokyo city shots in BH6 contain more geometry on screen than all of the shots on Frozen combined. In the past we would have used a matte painting for distant background stuff. It's pretty sweet.
- sitkack 12y agoWhich also means that in 10 years they can go back and reshoot old movies. "Back on location" is just a GUID in some PB scale object database.
- frozenport 12y ago>> Since cores are cheaper than humans I don't want to be a sourpuss, but there is a limit beyond which MPI stops scaling, when you look at the program runtime 60% of time is spent in MPI_Wait. Past 80k nodes you can't go much faster no matter how much money you got, I believe this is precisely the problem they address by intelligently grouping similar rays.
- z-e-r-o 12y agoYou forget that rendering a movie is almost infinitely scalable. Imagine, even when using only single-threaded code, you could scale for 130,000 nodes as there are about this many frames in a 90 minute movie at 24 fps. This is not totally true of course, for example you might want to do light or particle system calculation which persist across frames, but the general rendering bit is extremely scalable.
- berkut 12y agoBandwidth allowing of course - that's often the bottleneck when you're rendering production scenes with +300GB of textures :)
- boulos 12y agoEchoing what z-e-r-o said, nobody uses MPI to render individual frames. You do one frame per box and lots and lots of frames (all attacking the beefiest network file system you can find, but luckily it's all reads and thus easier to cache).
- berkut 12y agoYou wouldn't need MPI, just have multiple concurrent writes to a tiled EXR. We do it occasionally for stupidly big (>64K) frames. Doesn't work for deep though :)
- a_e_k 12y agoOff hand, I can't think of a reason why it wouldn't work for deep, too, other than perhaps disk space and I/O. Why do you say it wouldn't?
- boulos 12y agoHi Andrew ;). I've never dealt with the new OpenEXR 2.0 deep stuff, but looking at the spec (http://www.openexr.com/openexrfilelayout.pdf http://www.openexr.com/openexrfilelayout.pdf page 13) the Deep Tiled stuff seems to totally be ready for this. I would have guessed that there might have been some global compression option that wouldn't be workable, but the design clearly does this all per tile instead.
- berkut 12y agoIt would in theory work - our solution doesn't at the moment.