Disney's Hyperion Renderer

> As the linked article mentions, the solution was to optimize a massively-parallel algorithm by finding coherent rays that can be efficiently calculated together. It's a batch method: start casting a bunch of rays, identify similar rays and group them, calculate collisions for each group, cast reflected rays, identify similar rays and group them, etc. What I like about it conceptually is that in a way it treats light as a field rather than as individual directed rays.

How does this differ from "coherent ray tracing" and "ray packets", like people have been doing the last 15 years?

(e.g. "Interactive Rendering with Coherent Ray-Tracing" by Wald et al.: http://www.sci.utah.edu/~wald/Publications/2001/CRT/CRT.pdf)

Hyperion is an amazing renderer. Normal renderers are limited by memory, but as Hyperion traces millions of rays at the same time they can exploit coherence between rays and they can load in and subdivide geometry on demand. It also allows them to efficiently handle PTex textures, which the folks at Disney really like.

Here's the paper that explains some of the renderers details:

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

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.

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 also follows indirect rays that bounce around multiple objects in the scene on their path from the camera to the light source.

Practically speaking path tracing is going to give you a more real to life image at the expense of a slower rendering process.

Ray tracing is the art of tracing rays and detecting collision.

Ray tracing is used in photon mapping and path tracing.

With photon mapping you trace a ray from a light source and store the light energy for the area where the light hits an object.

With path tracing you ray trace a ray from the camera and every time you hit an object you check if you can see a light source from that spot. If true you return all the gathered energy back to the camera (pixel).

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 equation, a mathematical formulation of global illumination (takes diffuse, secular into account). It's a multidimensional integral equation. Unidirectional path tracing is an algorithm he introduced to solve the rendering equation. It uses several rays traced from pixels in the camera bouncing randomly through the scene. It's a Monte Carlo integration algorithm for solving the nasty integrals.

Photon mapping involves a pass algorithm tracing light from light sources into the scene, then a pass (like path tracing) gathering that light back at the camera. It better handles more complex light effects like caustics.

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.

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

This article[1] implies that there's a lot of cross-pollination with regard to computer graphics research and technology within the movie/VFX industry. So my guess is a bit of friendly competition that keeps spurring new innovation (similar to the browser wars).

[1] http://www.fxguide.com/featured/disneys-new-production-rende...

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 runtime cost over a shading grid of points using SSE - in path tracing, you generally shade one point at a time per ray vertex, although you can batch them up in some cases (but without significant ray re-ordering and deferring, after the first bounce this becomes less and less useful).

Disney also use Ptex for texturing, which doesn't really like incoherent shading points, so that was another reason to put effort into doing large scale re-ordering of rays and batching them up.

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.

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.

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 reflection, a surface looks equally bright from any direction, and you don't need to recalculate anything if you move the camera. The big disadvantage is there's no soecular reflection, so light bounces wrong off anything that should have been glossy.

I'm not aware of any attempts to do it "backward," and I can't think of how that would work. The camera in radiosity is essentially an afterthought; you can calculate the entire scene without even having one, and the view you get afterward is more of a data visualization of that result than anything that involved the camera in a fundamental way.

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.