Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Disney’s New Production Renderer ‘Hyperion’

fxguide.com

Post reply on HN
Print view View original

21–27 of 27 posts

Re: Disney’s New Production Renderer ‘Hyperion’

#21

Post by Igglyboo »

rustyconover wrote: post #7

Whenever I read about new renderers I think I'm completely intellectually inept even with what I think is a reasonably well-rounded computer science education. It is like reading about string theory in a way. Sure, I can grasp the concepts, but the details and minutia are fascinating and admittedly a little beyond my immediate comprehension. I remember when POV-RAY was amazing when it ran all night to produce just on…

I wouldn't worry about it too much, Computer Science is past the point where you can have intricate knowledge of all of it. Knowledge of the existence of most things is good enough imo.

Also it goes both ways, I doubt the people writing these renderers have intricate knowledge of modern networking or web stacks etc.

Re: Disney’s New Production Renderer ‘Hyperion’

#22

Post by boulos »

frozenport wrote: post #14
boulos wrote: post #9

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 pr…

>> 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.

Echoing 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).

Re: Disney’s New Production Renderer ‘Hyperion’

#23

Post by berkut »

boulos wrote: post #22
frozenport wrote: post #14

Earlier quoted context omitted.

>> 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.

Echoing 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).

You 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 :)

Re: Disney’s New Production Renderer ‘Hyperion’

#24

Post by a_e_k »

berkut wrote: post #23
boulos wrote: post #22

Earlier quoted context omitted.

Echoing 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).

You 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 :)

Off 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?

Re: Disney’s New Production Renderer ‘Hyperion’

#25

Post by boulos »

a_e_k wrote: post #24
berkut wrote: post #23

Earlier quoted context omitted.

You 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 :)

Off 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?

Hi Andrew ;).

I've never dealt with the new OpenEXR 2.0 deep stuff, but looking at the spec (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.

Re: Disney’s New Production Renderer ‘Hyperion’

#26

Post by berkut »

a_e_k wrote: post #24
berkut wrote: post #23

Earlier quoted context omitted.

You 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 :)

Off 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?

It would in theory work - our solution doesn't at the moment.

Re: Disney’s New Production Renderer ‘Hyperion’

#27

Post by sitkack »

davvid wrote: post #13
boulos wrote: post #9

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 pr…

An 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.

Which 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.
Post reply on HN