Disney's Hyperion Renderer • Hacker News Board

Re: Disney's Hyperion Renderer

#41

Post by CyberDildonics » Mon, Aug 03, 2015, 6:49 PM UTC

mattpharr wrote: post #37

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…

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…

I'll just say that I don't want to dismiss anything except for exaggerated marketing. I think it is reasonable to say that I should ignore it though.

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

I'm %100 with you. I love seeing the results of cache coherency used in a real scenario. I was only trying to say that the actual imagery could have been done in other renderers, albeit with more pain and I would guess more attention to level of detail.

So I'm not trying to downplay anything except for the idea that the actual movie itself couldn't have been done without cache coherent batch ray tracing, when in reality it is a big optimization that came from a bit of a leap of faith, which I think is significant enough to pay attention to.

Re: Disney's Hyperion Renderer

#42

Post by gioele » Mon, Aug 03, 2015, 6:57 PM UTC

In the first comparison I see that the shadows in the picture generated by Hyperion are way too fuzzy compared to the reference photo. Is this a problem of the technique or just the result of the way in which lightning and polygons have been set up?

Re: Disney's Hyperion Renderer

#43

Post by tomvbussel » Mon, Aug 03, 2015, 7:01 PM UTC

mattpharr wrote: post #37

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…

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…

I completely agree with you that the information in that paper is excellent and I think it's amazing that Disney is so willing to share so much information about their renderer, even though their sister company Pixar sells a renderer.

The question though is whether or not this paper should have been published at EGSR. Personally I think that an EGSR paper should either propose a novel idea or should provide a good survey of the field. I don't think this paper succeeds at either of those. Their method is 'simply' a combination of already published ideas and I don't think that they do a very good job at comparing those existing ideas.

Personally, I think this paper would have been better suited as a talk at SIGGRAPH, a publication at JCGT or a technical report (like Pixar). So: great paper, wrong venue.

Re: Disney's Hyperion Renderer

#44

Post by CyberDildonics » Mon, Aug 03, 2015, 7:04 PM UTC

mattpharr wrote: post #39

CyberDildonics wrote: post #33

Earlier quoted context omitted.

> 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://resea…

I say that based on what I've seen and claims I've heard - optix, prman unloading and loading procedurals, a renderer making that claim a long time ago (maybe finalrender?) In any event I don't know if any work particularly well, for the same reasons that Hyperion succeeds of course.

I'm actually more surprised that you would think of sorting and batching of rays as a feat of engineering, I can't imagine it seems all that difficult to you after all your experience.

Re: Disney's Hyperion Renderer

#45

Post by CyberDildonics » Mon, Aug 03, 2015, 7:14 PM UTC

tomvbussel wrote: post #43

mattpharr wrote: post #37

Earlier quoted context omitted.

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…

I completely agree with you that the information in that paper is excellent and I think it's amazing that Disney is so willing to share so much information about their renderer, even though their sister company Pixar sells a renderer. The question though is whether or not this paper should have been published at EGSR. Personally I think that an EGSR paper should either propose a novel idea or should provide a good su…

I'm actually really glad they got the paper out there as a small pdf (and I'm actually glad they compared it to other commercial renderers). The reason is that it shows very real world performance results. Not only that but cache coherency optimization results are shocking and illuminating to many people because it seems so counter intuitive when there technically aren't more instructions being ran.

Every paper I read now I am looking for all the things that were left out, how the comparisons have been changed for each scene to make that particular algorithm look good etc.

It answered a big question lingering in my mind that I haven't been able to actually try out.

Re: Disney's Hyperion Renderer

#46

Post by cbsmith » Mon, Aug 03, 2015, 9:21 PM UTC

tomvbussel wrote: post #28

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…

Thanks. I had heard about it last year, and so thought it was all old news.