4 ms·

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 projec

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 http://www.acm.uiowa.edu/uicc/speakers.html#nichols

xwintermutex 11y ago
> 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 http://www.sci.utah.edu/~wald/Publications/2001/CRT/CRT.pdf)
- couchand 11y ago
  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.
- tomvbussel 11y ago
  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/publication_asset/70/asset/Sorted_Deferred_Shading_For_Production_Path_Tracing.pdf https://disney-animation.s3.amazonaws.com/uploads/production... [2] http://www.sci.utah.edu/~wald/Publications/2011/singleray_hybrid/hybrid.pdf http://www.sci.utah.edu/~wald/Publications/2011/singleray_hy... [3] http://fileadmin.cs.lth.se/graphics/research/papers/2014/drst/ http://fileadmin.cs.lth.se/graphics/research/papers/2014/drs...
tomvbussel 11y ago
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/publication_asset/70/asset/Sorted_Deferred_Shading_For_Production_Path_Tracing.pdf https://disney-animation.s3.amazonaws.com/uploads/production...
CyberDildonics 11y ago
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.
- tomvbussel 11y ago
  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.

xwintermutex 11y ago

> 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 http://www.sci.utah.edu/~wald/Publications/2001/CRT/CRT.pdf)

couchand 11y ago
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.
tomvbussel 11y ago
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/publication_asset/70/asset/Sorted_Deferred_Shading_For_Production_Path_Tracing.pdf https://disney-animation.s3.amazonaws.com/uploads/production... [2] http://www.sci.utah.edu/~wald/Publications/2011/singleray_hybrid/hybrid.pdf http://www.sci.utah.edu/~wald/Publications/2011/singleray_hy... [3] http://fileadmin.cs.lth.se/graphics/research/papers/2014/drst/ http://fileadmin.cs.lth.se/graphics/research/papers/2014/drs...

tomvbussel 11y ago

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/publication_asset/70/asset/Sorted_Deferred_Shading_For_Production_Path_Tracing.pdf https://disney-animation.s3.amazonaws.com/uploads/production...

CyberDildonics 11y ago

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.

tomvbussel 11y ago
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.