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

Disney's Hyperion Renderer

disneyanimation.com

Post reply on HN
Print view View original

31–40 of 46 posts

Re: Disney's Hyperion Renderer

#31

Post by dr_zoidberg »

wlesieutre wrote: post #17
dr_zoidberg wrote: post #11

They talk about the bounces of light, which reminds me of radiosity global illumination[1]. I'm left wondering if this idea of going "from the camera to the light sources" is applied in any particular radiosity implementation, and which are it's differences in respecto to the basic form of the algorithm (that would be "from the light sources to the camera"). [1] https://en.wikipedia.org/wiki/Radiosity_%28computer_gra…

Radiosity doesn't track where light is coming from or going to, just the total amount of light hitting a face from any direction. It's built around the simplification that all surfaces are perfectly diffuse so that it can iterate through all the faces and exchange light with every other face. This has its advantages and disadvantages, the biggest advantage being that it's "view independent." Since there's no specular…

Sounds about right. Not having the time to work on implementing this sort of thing (even as a toy project) leaves me at the point where I sometimes read about the algorithms but can't see through them into the details.

Re: Disney's Hyperion Renderer

#32

Post by Xcelerate »

kuya wrote: post #10
Xophmeister wrote: post #2

What's the difference between path tracing, ray tracing and photon mapping? I'd never heard of path tracing before now and the video makes it sound the same as ray tracing/casting, but what I've read implies otherwise (but I'm not sure how). Clearly it's different to photon mapping, but what ever happened to that: Was it too computationally expensive for the pay-off?

Ray tracing is a more generic term that covers rendering techniques which trace rays between a camera and a scene. Back in the day everyone used Whitted style ray tracers to render shiny metal blobs because secular reflections are trivially handled with ray tracing. Unfortunately other physical aspects of light like diffuse reflections were not handled by early ray tracing algorithms. Kajiya introduced the rendering…

> It better handles more complex light effects like caustics.

I wouldn't say better. I would say it provides an approximation to the rendering equation more quickly than path tracing does. However, photon mapping is a biased algorithm, which means that if you average many independent renderings together, they won't converge on the correct (exact) image. Path tracing methods (bi-directional, Metropolis, etc.) converge on the exact solution, regardless of how noisy each individual rendering is. (However, it may be the case that an unwieldy number of samples is required for tricky caustics, so in practice, path tracing may fail to produce a correct result because of high variance.)

Re: Disney's Hyperion Renderer

#33

Post by CyberDildonics »

tomvbussel wrote: post #27
CyberDildonics wrote: post #22

Earlier quoted context omitted.

I'm going to deflate the marketing spin a little bit since large companies tend to go down the route of 'there was an impossible task and we use outside the box thinking to do what no one else could'. Tracing batch rays, sorting them for better coherency and sorting the shading for coherency are not new ideas, but they are long over due to be used heavily in offline, cpu, ray traced rendering situations. Large amount…

I mostly agree with you. From an engineering standpoint I think that Hyperion is an amazing renderer and I'd love to dig into its source code. From an academic standpoint however I think that their paper on it wasn't very interesting. I don't mind reading about the details of a production renderer, as there is a whole lot of info on writing production renderers. But I don't think that it should have been published at…

> There were no real new ideas in that paper that were worth publishing.

The real world speed improvements from specific methods are the significant part. There are many ideas floating around, not all of them work out once you discover all the comparisons and data omitted from an academic paper.

>I do think you should give them more credit on the engineering side though. Using large amounts of geometry has been done before, but renderers such as RenderMan and Arnold require that all geometry fits in the memory at once.

This is out of core tracing and is great that they implemented it, but neither out of core tracing and sorting rays are feats of engineering.

It has actually been done many times in both academics and commercial renderers from at least a decade ago. SIMD is also used to various extents in any decent renderer to varying degrees of success. Sorting into packets isn't the only way to use SIMD, or even the only way to use to scale SIMD use to wider lanes. Interestingly Skylake should have fast gather/scatter operations which will change the effectiveness of various techniques.

Basically good design choices and some practical knowledge from trial and error has been heavily exaggerated by marketing. I would guess that the actual render programmers would say the same. This isn't a breakthrough, it is a refinement and that's good enough. I love what they did, but to carry the torch that the impossible was made possible is disingenuous.

Re: Disney's Hyperion Renderer

#34

Post by winslow »

pmorici wrote: post #5

Anyone have any insight as to why Disney would build a separate rending engine when they own Pixar and could use their renderman engine?

This is mostly due to the two companies being run completely separately. Resources are not shared between the two because Disney Animation is unionized where Pixar is not. It can get messy when you take non union work from Pixar and use Union work at Disney Animation and vice versa.

Re: Disney's Hyperion Renderer

#35

Post by tomvbussel »

Xcelerate wrote: post #32
kuya wrote: post #10

Earlier quoted context omitted.

Ray tracing is a more generic term that covers rendering techniques which trace rays between a camera and a scene. Back in the day everyone used Whitted style ray tracers to render shiny metal blobs because secular reflections are trivially handled with ray tracing. Unfortunately other physical aspects of light like diffuse reflections were not handled by early ray tracing algorithms. Kajiya introduced the rendering…

> It better handles more complex light effects like caustics. I wouldn't say better . I would say it provides an approximation to the rendering equation more quickly than path tracing does. However, photon mapping is a biased algorithm, which means that if you average many independent renderings together, they won't converge on the correct (exact) image. Path tracing methods (bi-directional, Metropolis, etc.) converg…

Photon Mapping might be biased, but it's extremely easy to make it consistent by using the method outlined by Knaus and Zwicker [1]. Using that method photon mapping will converge to the right result. Even without progressive photon mapping you can choose a photon radius that won't cause visible errors.

[1] http://cgg.unibe.ch/publications/2011/progressive-photon-map...

Re: Disney's Hyperion Renderer

#36

Post by mineral_or_veg »

tomvbussel wrote: post #14
shocks wrote: post #6

The Pixar online library is a really great resource. http://graphics.pixar.com/library/

They have some pretty cool papers on there, but the few landmark papers that Pixar published were all published in the 80s. Here is a better source for papers (SIGGRAPH, Eurographics and EGSR have the best papers on rendering): http://kesen.realtimerendering.com/ The Hyperion renderer was made by Disney, not Pixar by the way. Pixar only uses their own RenderMan renderer. Disney uses a mix of Hyperion and RenderMan, a…

"Disney uses a mix of Hyperion and RenderMan, as Hyperion is not useable for test renders, as it can take up to 15 minutes until a pixel will appear on the screen, as they trace millions of rays at the same time."

None of the things you claim in this sentence are true. Disney does not use PRman at all anymore.

Re: Disney's Hyperion Renderer

#37

Post by mattpharr »

CyberDildonics wrote: post #22
couchand wrote: post #13

I saw Greg Nichols give a talk about this at the UICC [0] this year. It was a very entertaining talk covering the business and technical aspects of this project. From the start the art team on Big Hero 6 wanted to make a really big movie. They envisioned those big sweeping shots of San Fransokyo that made the technical folks shudder. They have a massive rendering farm at their disposal but still probably wouldn't be…

I'm going to deflate the marketing spin a little bit since large companies tend to go down the route of 'there was an impossible task and we use outside the box thinking to do what no one else could'. Tracing batch rays, sorting them for better coherency and sorting the shading for coherency are not new ideas, but they are long over due to be used heavily in offline, cpu, ray traced rendering situations. Large amount…

Given that this is HN, I'd encourage reading and commenting on the substance of the technical paper rather than the marketing webpage.

Those ideas have indeed been around for a long time; the paper nicely cites all of the related research work. (Including among many others, a SIGGRAPH paper I wrote on the topic 18 years ago.)

I think the paper is excellent. First, there's a big gap between academic papers on a topic and the experience of actually building a real system that works for real movies. It's unusual for people in industry to take the time to write up their experiences building these systems, so I salute their making this contribution to general knowledge about rendering systems.

It's easy to carp about "all could have been done before"; that seems like an argument that could be applied to try to dismiss just about anything.

Re: Disney's Hyperion Renderer

#38

Post by [deleted] »

tomvbussel wrote: post #14
shocks wrote: post #6

The Pixar online library is a really great resource. http://graphics.pixar.com/library/

They have some pretty cool papers on there, but the few landmark papers that Pixar published were all published in the 80s. Here is a better source for papers (SIGGRAPH, Eurographics and EGSR have the best papers on rendering): http://kesen.realtimerendering.com/ The Hyperion renderer was made by Disney, not Pixar by the way. Pixar only uses their own RenderMan renderer. Disney uses a mix of Hyperion and RenderMan, a…

[deleted]

Re: Disney's Hyperion Renderer

#39

Post by mattpharr »

CyberDildonics wrote: post #33
tomvbussel wrote: post #27

Earlier quoted context omitted.

I mostly agree with you. From an engineering standpoint I think that Hyperion is an amazing renderer and I'd love to dig into its source code. From an academic standpoint however I think that their paper on it wasn't very interesting. I don't mind reading about the details of a production renderer, as there is a whole lot of info on writing production renderers. But I don't think that it should have been published at…

> There were no real new ideas in that paper that were worth publishing. The real world speed improvements from specific methods are the significant part. There are many ideas floating around, not all of them work out once you discover all the comparisons and data omitted from an academic paper. >I do think you should give them more credit on the engineering side though. Using large amounts of geometry has been done…

> neither out of core tracing and sorting rays are feats of engineering

Presumably this statement based on your having shipped a production renderer that does these things?

> It has actually been done many times in both academics and commercial renderers from at least a decade ago

Academics, yes. Commercial--citation please? The only one I'm aware of is Weta's PantaRay, which is from only ~5 years ago (https://research.nvidia.com/publication/pantaray-fast-ray-tr...).

Re: Disney's Hyperion Renderer

#40

Post by mineral_or_veg »

mineral_or_veg wrote: post #36
tomvbussel wrote: post #14

Earlier quoted context omitted.

They have some pretty cool papers on there, but the few landmark papers that Pixar published were all published in the 80s. Here is a better source for papers (SIGGRAPH, Eurographics and EGSR have the best papers on rendering): http://kesen.realtimerendering.com/ The Hyperion renderer was made by Disney, not Pixar by the way. Pixar only uses their own RenderMan renderer. Disney uses a mix of Hyperion and RenderMan, a…

"Disney uses a mix of Hyperion and RenderMan, as Hyperion is not useable for test renders, as it can take up to 15 minutes until a pixel will appear on the screen, as they trace millions of rays at the same time." None of the things you claim in this sentence are true. Disney does not use PRman at all anymore.

Sorry, I guess what I meant was that Hyperion is perfectly capable of being used in test renders. The amount of time before you see any resolved pixels is of course dependent on the size of your scene, the desired resolution, etc. It could take 15 minutes before a pixel shows up, but that's not a standard case for production test renders in an artist's daily work.
Post reply on HN