Live data from Hacker News

Disney's Hyperion Renderer

disneyanimation.com

11–20 of 46 posts

Re: Disney's Hyperion Renderer

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

Re: Disney's Hyperion Renderer

#12
post #10

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…

Stupid phone: secular-specular

Re: Disney's Hyperion Renderer

#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 able to render all the shots in time for the release; for one reason, because the art folks kept making changes, and for another, because they contain so many entities. A handful of folks on the rendering team built a proof-of-concept renderer with support for the global-illumination look they wanted while also being able to handle the massive scale.

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.

Their initial tests were rendering an infinite plane of generated buildings. The dystopian metropolis was mesmerizing, and I think Disney would be wise to come up with some dark plot line to set there. Anyway, someone way at the top (the director or art director I think) saw the proof-of-concept renderings and decided that it was the perfect tool to attain their vision of this movie, which, by the way, has a hard release date something like three months away.

So they proceeded to turn the proof-of-concept into a production-grade renderer in time to render all the frames and save the movie. And somehow they pulled it off, they released a really beautiful movie, and they wrote a paper about it, too.

[0]: http://www.acm.uiowa.edu/uicc/speakers.html#nichols

Re: Disney's Hyperion Renderer

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

Re: Disney's Hyperion Renderer

#15

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…

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

Re: Disney's Hyperion Renderer

#16

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…

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

Re: Disney's Hyperion Renderer

#17

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

Re: Disney's Hyperion Renderer

#18

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…

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

I've already gone beyond my understanding of the technical details. The paper probably goes into it (linked in the sibling), and it also looks like it cites Wald.

Just noticed it also has the proof-of-concept city scene I mentioned on the last page.

Re: Disney's Hyperion Renderer

#19

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…

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

They're generating millions of rays to trace them at the same time, so they should be able to use packet tracing and they seem to use that [1]. Incoherent rays can be extremely troublesome when tracing packets, as you could be entering a branch of the BVH for just a few rays in the packets and in that case you're wasting a large part of the SIMD vector. There has been some research to alleviate that [2, 3] and creating more cohorent batches alleviates it even more. One of the other big problems of packet tracing is that there is no good way to handle motion blur, but if they're generating millions of rays at once they can just create packets with rays that are all in the same time interval.

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

[2] http://www.sci.utah.edu/~wald/Publications/2011/singleray_hy...

[3] http://fileadmin.cs.lth.se/graphics/research/papers/2014/drs...

Re: Disney's Hyperion Renderer

#20
post #3

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 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 only handle specular reflection and transmission, and direct illumination. This is called Whitted ray tracing and is probably what you're referring to.
Post reply on HN