|
|
|
|
|
|
by tomvbussel
3976 days 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. |
|
|
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 before, but renderers such as RenderMan and Arnold require that all geometry fits in the memory at once.
This is out of core tracing and is great that they implemented it, but neither out of core tracing and sorting rays are feats of engineering.
It has actually been done many times in both academics and commercial renderers from at least a decade ago. SIMD is also used to various extents in any decent renderer to varying degrees of success. Sorting into packets isn't the only way to use SIMD, or even the only way to use to scale SIMD use to wider lanes. Interestingly Skylake should have fast gather/scatter operations which will change the effectiveness of various techniques.
Basically good design choices and some practical knowledge from trial and error has been heavily exaggerated by marketing. I would guess that the actual render programmers would say the same. This isn't a breakthrough, it is a refinement and that's good enough. I love what they did, but to carry the torch that the impossible was made possible is disingenuous.