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

21–30 of 46 posts

Re: Disney's Hyperion Renderer

#21

Post by tomvbussel »

berkut wrote: post #9
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?

Because until last year when Pixar released PRMan 19 RIS, PRMan was not that good at ray tracing / path tracing - the REYES method of rendering and shading didn't scale as well for big complex scenes when global illumination and raytraced light occlusion was done. The RSL shading language was also causing a rather large overhead of shading time as it was an interpreted language that could no longer amortise its runti…

The REYES algorithm isn't really the problem, you can just generate an acceleration structure and shade each shading point using ray tracing [1]. The REYES algorithm is just an algorithm that generates shading points and determines in which pixels those points are visible, it puts no restrictions on how you shade those points. The downside to mixing REYES and ray tracing is that you have to keep two representations of the geometry in memory, but that doesn't mean you can't combine the two.

The main problem with RenderMan before version 19 was that it didn't have a good acceleration structure and that you basically had to implement a path tracer in RSL on your own. Pixar wrote a path tracer in RSL for Monster's University, so Disney could have just used that. I doubt that they would write their own renderer if they could have just asked Pixar to implement a better acceleration structure in PRMan, so there were obviously different reasons too.

I think Ptex was an important reason for them to write their own renderer, as they seem to put a lot of focus on textures in their paper on the architecture of Hyperion [2]. Hyperion's architecture also allows them to use packet tracing and to load and subdivide geometry on demand, which is also really great.

[1] http://www.realtimerendering.com/resources/RTNews/html/rtnv1...

[2] https://disney-animation.s3.amazonaws.com/uploads/production...

Re: Disney's Hyperion Renderer

#22

Post by CyberDildonics »

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 amounts of geometry have been done in movies for a long time, so Disney didn't really do anything that couldn't have been done before. All the same tracing a path of light one at a time while interlacing the shading is terrible for performance so it is great that Disney was able to reap the benefits. It is something that should have been obvious to anyone who understood cache performance in CPUs, but now at least people have something non-academic to point to.

Re: Disney's Hyperion Renderer

#23

Post by CyberDildonics »

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?

The real answer to this is basically that the two companies aren't all that integrated, even today. At the same time, renderman was still using ray tracing as part of it's hybrid REYES architecture.

Even so, they could have made it with renderman. Presentations saying 'this wouldn't have been possible' are more marketing than reality. It was more likely to be a combination of the right time to pitch creating a new ray tracer to see how much could be gained through batching while also having a renderer they could control and make sure was modern.

Re: Disney's Hyperion Renderer

#24

Post by dahart »

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?

The other answers here are correct, but to shed a little more light on it, the main development of path tracing over ray tracing is that path tracing involves Monte Carlo integration to simulate many effects, the big one being Global Illumination, but depth of field and soft shadows as well. What this means is that at every step along a ray path, you carefully pick a new direction for the next ray segment that is randomized according to whatever effect that segment corresponds to, whether it's the surface material there, or the camera lens or the area/volume light source, or something else. The implication of this randomizing / Monte Carlo integration is that it typically takes many ray paths to get the color for a single pixel. (You can use only one or just a few, and your result will be very noisy.)

When people talk about ray tracing as something different than path tracing, they usually mean the first form of ray tracing that only did direct diffuse lighting, point light sources, simplistic materials, and multiple bounces of perfect specular reflections. (Aka recursive ray tracing.)

Note that not everyone makes a distinction between path tracing and ray tracing, you can easily find lots of examples of people referring to ray tracing and talking about GI and Monte Carlo techniques. "Ray tracing" is evolving to incorporate modern developments.

Re: Disney's Hyperion Renderer

#25

Post by berkut »

tomvbussel wrote: post #21
berkut wrote: post #9

Earlier quoted context omitted.

Because until last year when Pixar released PRMan 19 RIS, PRMan was not that good at ray tracing / path tracing - the REYES method of rendering and shading didn't scale as well for big complex scenes when global illumination and raytraced light occlusion was done. The RSL shading language was also causing a rather large overhead of shading time as it was an interpreted language that could no longer amortise its runti…

The REYES algorithm isn't really the problem, you can just generate an acceleration structure and shade each shading point using ray tracing [1]. The REYES algorithm is just an algorithm that generates shading points and determines in which pixels those points are visible, it puts no restrictions on how you shade those points. The downside to mixing REYES and ray tracing is that you have to keep two representations o…

It was the problem, because doing REYES hiding you suffer the huge "overdrawing" issue, where you need to set the shading rate per object in the scene based on its size on screen such that it doesn't get too much shading. If it had too much shading (the shading rate was too low), many more rays will be sent. And this is because REYES shades stuff before it sees if it's visible, whereas raytracing from the camera (with the raytrace hider in PRMan) only shades the points which are visible, so it scales much more on complex scenes (when GI comes into the picture - without GI REYES can cope easily as it pages everything).

Re: Disney's Hyperion Renderer

#27

Post by tomvbussel »

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…

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 EGSR. There were no real new ideas in that paper that were worth publishing. The paper could have had some merit if they provided a good comparison between their architecture and other architectures, but sadly they decided to compare their renderer with other off the shelf renderers. Very little is known about the architectures of those renderers and as they all have their own implementations of acceleration structures, texturing and other shared components, they aren't comparable at all. It would have been much nicer if they implemented their algorithm in a framework such as Mitsuba, so that it could be compared with other algorithms.

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. Tracing large batches of rays at the same time allows you to load in or subdivide geometry on demand, which makes the size of the harddrive and the size of the individual meshes the limit, instead of the memory being the limit. Their scheme also allows for creating good ray packets, which clearly is needed if we want to reap the benefits of Moore's law, as those extra transistors mostly translate to wider SIMD vectors instead of higher clockspeeds and simply increasing the amount of children of a BVH node won't scale well. Reordering the rays allows you to create coherent packets out of incoherent rays and it allows you to efficiently handle motion blur, as all rays in a packet need to be in the same time interval, which allows you to efficiently make use of those wider SIMD vectors.

I'm certain they could have produced Big Hero 6 without Hyperion, but Hyperion gave their artists a lot of freedom by removing some of the technical limitations.

Re: Disney's Hyperion Renderer

#28

Post by tomvbussel »

cbsmith wrote: post #26

This article is from 2013. Why is it getting attention now?

This web page is from this month, not 2013. They published a paper on the architecture of Hyperion in 2013, but that never received a lot of attention as it appeared out of the blue and it was published at a 'minor' conference. As most people thought that Disney was still using RenderMan, people never realized that they were actually using that architecture in a production renderer. A few months ago FXGuide published an article on Hyperion and in the past few months there have been a few talks by Disney on it, but this is the first public article by Disney specifically about their renderer. And besides, there aren't a whole lot of discussions on Hacker News on offline rendering, so this article is a good opportunity to discuss graphics.

Re: Disney's Hyperion Renderer

#29

Post by DonHopkins »

tomvbussel wrote: post #20
pmorici wrote: post #3

Earlier quoted context omitted.

The way I understand it; ray tracing and path tracing are the same conceptually except for how so called 'global illumination' (GI) is calculated. Ray tracing uses a short cut that computes the value with an equation that can be applied efficiently to the entire image. Path tracing on the other hand calculates the GI by tracing not only direct rays from the camera lens bouncing off an object to the light sources but…

This is wrong. Ray tracing simply is a way to determine visibility between two points, just like the Z-buffer. Ray tracing won't produce a color on its own. Path tracing on the other hand is a method which uses ray tracing to solve the light transport integral. It creates paths between the camera and the light using ray tracing and then it calculates the contribution of that path to the image. Most toy ray tracers on…

Is the light transport integral isomorphic to what Heckbert's paper [1] refers to as "gratuitous partial differential equations [2]," as explained by Fuller [3]?

>The “begetted” eightness as the system-limit number of the nuclear uniqueness of self-regenerative symmetrical growth may well account for the fundamental octave of unique interpermutative integer effects identified as plus one, plus two, plus three, plus four, as the interpermuted effects of the integers one, two, three, and four, respectively; and as minus four, minus three, minus two, minus one, characterizing the integers five, six, seven, and eight, respectively [3].

[1] http://www.ecse.rpi.edu/~wrf/Teaching/graphics-s2005/heckber...

[2] https://wattsupwiththat.files.wordpress.com/2012/01/bg-equat...

[3] Fuller. R.B. Synergetics. MacMillan, New York, 1975,~. 125.

Re: Disney's Hyperion Renderer

#30

Post by dahart »

tomvbussel wrote: post #20
pmorici wrote: post #3

Earlier quoted context omitted.

The way I understand it; ray tracing and path tracing are the same conceptually except for how so called 'global illumination' (GI) is calculated. Ray tracing uses a short cut that computes the value with an equation that can be applied efficiently to the entire image. Path tracing on the other hand calculates the GI by tracing not only direct rays from the camera lens bouncing off an object to the light sources but…

This is wrong. Ray tracing simply is a way to determine visibility between two points, just like the Z-buffer. Ray tracing won't produce a color on its own. Path tracing on the other hand is a method which uses ray tracing to solve the light transport integral. It creates paths between the camera and the light using ray tracing and then it calculates the contribution of that path to the image. Most toy ray tracers on…

You're probably right, but nobody I know calls it "Whitted ray tracing" unless Turner is there in the room, or some point is being made about or in reference to his paper specifically. ;) In my experience, graphics people generally do mean producing colors for pixels when they say "ray tracing". But I think physicists would assume "ray tracing" means visibility queries and nothing more.

When someone says 'ray tracing' to me today, before they elaborate on what they mean, I assume they're talking about using straight line segment visibility tests probably to make some kind of picture, probably using Monte Carlo techniques, probably for global illumination. So, they might mean path tracing, or one of the (many) other ways to simulate lighting, or my assumption might be wrong, but that's okay because language is fun, and vague, overridden and imperfect terms allow us to have longer conversations. :)

Post reply on HN