tomvbussel

Here is the full list of papers with links to preprints for the papers presented at SIGGRAPH 2018:

http://kesen.realtimerendering.com/sig2018.html

RenderMan traces ray streams of a few thousands rays (at least not millions like Disney's Hyperion), right? Does that really help that much with reducing the shading costs? It probably makes a large difference for shading the initial hit point, but nowadays it's not uncommon to trace paths of more than 10 bounces. It seems very unlikely to me that it gives a significant speed-up with that level of incoherence and the high complexity of production scenes.

Some context: During a panel on production renderers at SIGGRAPH [0] it was mentioned that most rendering research was not really usable for production rendering, as those algorithms are unable to handle the complexity of production scenes. Matt Pharr (one of the authors of pbrt [1]) asked the panelists to release production datasets for research purposes. Walt Disney Animation Studios is now following up on his request by releasing these two datasets. Yining Karl Li of Disney [2] and the readme for the Moana dataset [3] have some more info.

It's absolutely amazing that Disney is doing this, especially as the license is quite permissive and also allows the usage for non-research purposes.

[0] https://dl.acm.org/citation.cfm?id=2927384

[1] http://pbrt.org/

[2] https://blog.yiningkarlli.com/2018/07/disney-animation-datas...

[3] https://s3-us-west-1.amazonaws.com/assets.disneyanimation.co...

The per-thread caches are not strictly necessary, but you don't want threads to block because they can't stream in geometry to memory. You want some upper bound on the amount of memory each thread needs for geometry (each thread could try to ray intersect a different mesh). Dividing geometry into fixed sized chunks gives you this upper bound (max N chunks per thread).

Ray re-ordering is indeed a nightmare, but sorting very large ray batches (millions of rays) into coherent ray streams is less of a hassle, and it should enable coherent geometry access (which amortizes the cost of those reads, not sure to what extent).

Yup, I meant paging geometry. The problem with just doing a two level BVH is that some models can be very large, while others may be much smaller, which makes it hard to reserve memory for the geometry cache (even if it just fits one model per thread). Which means that you can store fewer rays in memory, and I'm not really a fan of constantly writing rays to disk. I was thinking of just cutting off subtrees of the BVH and storing those on disk, which makes it possible to assign just a few megabytes of memory to each thread for caching geometry. Not sure how efficient that would be though, probably a bit faster than rebuilding part of the BVH every time (especially when using high quality BVHs with spatial splits). Shouldn't be too bad with large ray batches, sorting and ray streams.

They do mention some tests with "out-of-core rendering of scenes with massive amounts of geometry" in the paper, but there isn't much info on it. AFAIK their patents mention streaming in geometry too.

I know that buying more RAM is probably easier, but it would be interesting to render very large scenes on commodity hardware. I guess paging in geometry is just too much of a hassle, you constantly have to stream in geometry to memory; to compute surface derivates, to do subsurface scattering, to sample arbitrary geometry lights, etc.

There's very little info in the Disney paper on geomapping, do you have any ideas on how they do it?

I guess that you don't want to page in full models (as you either need a very large amount of memory per thread, which means smaller ray batches, or you need to have a shared cache, which means waiting on other threads). So you'll probably need something similar to Toro (as described by Pharr et al.), which just doesn't seem very efficient to me (as grids have improved little compared to BVHs).

Seems like it took them a few minutes per frame to render TS1 in 2011 [1], not sure if that's with the higher resolution.

[1] https://www.quora.com/How-much-faster-would-it-be-to-render-...

They gave Yelp two options: either disable crawling in robots.txt, which means that Yelp won't show up in Google's results at all, or accept that Google will copy Yelp reviews without linking back. This is quite similar to what Microsoft was doing in my opinion.

I wonder how they got that number. If getting Android notifications counts as 'using Facebook' then I'm one of those one billion.

The same can be said about Windows, yet both the European Union and the United States accused Microsoft of abusing their monopoly by bundling Internet Explorer with Windows. This antitrust against Google is really similar.

Google has a search engine monopoly (at least in Europe), this gives them the obligation not to abuse this. If they're using their monopoly to promote other services (such as when directly show Maps in the results, without offering other providers of maps the same option) or if they're scraping content without linking back (such as with Yelp), they're abusing this monopoly.

I think this is aimed at middle/high school students. It probably can be interesting for adults, but I'd really recommend picking up a book such as Fundamentals of Computer Graphics by Shirley and Marschner [1].

[1] https://www.cs.cornell.edu/~srm/fcg3/

Yeah it was a great learning tool. pbrt is a good learning tool, but sadly it already implements most of the basics. Courses at Cornell and ETH Zürich used a small rendering framework called Nori [1], which is a pretty good learning tool. Shadertoy is nice, but perhaps a bit annoying to work in (as it involves a lot of tricks). I guess the best way to learn is to write your own ray tracer, but that takes a lot of time.

The current edition of Physically Based Rendering still uses literate programming, but most of the maths are separated from the code, so you can skip over most of the code. Even if you can't stand I can really recommend reading it, as it's a great book. Shirley's Realistic Ray Tracing is still very useful these days, but obviously it's lacking the state of the art. If you really want to avoid any code you should read Veach's PhD thesis [2] and then some papers on BSDFs [3], shapes [4] and ray tracing acceleration [5].

[1] http://wjakob.github.io/nori/

[2] http://graphics.stanford.edu/papers/veach_thesis/

[3] http://www.cs.cornell.edu/~srm/publications/EGSR07-btdf.html

[4] http://www.graphics.cornell.edu/pubs/1997/MT97.html

[5] http://www.nvidia.com/object/nvidia_research_pub_012.html

I guess I didn't fully understand your post then, I thought you meant that the Reyes algorithm is an "inferior estimation" and that it might be beneficial to add it to a renderer, but neither is the case. But it isn't an inferior estimation (just a different way of computing things) and you don't want to use the Reyes algorithm in practice as scenes either barely fit in memory or they don't fit in memory at all (and in that case you want your memory usage to be as efficient as possible to avoid reading from the disk as much as possible).

The CG by UC Berkeley on EdX is a great starting point. One of the exercises involves building a simple ray tracer. A slightly more advanced source on ray tracing is http://www.scratchapixel.com/. Of course the best way to learn about ray tracing is by reading Physically Based Rendering: From Theory to Implementation by Pharr and Humphreys.

Pixar has ditched RSL in favor of BSDFs written in C++, so there is no real reason for learning RSL anymore. Open Shading Language (OSL) is a new shading language which is getting more and more use in the industry, but it's completely different by design.

The REYES algorithm is an algorithm that can very quickly produce batches of shading points (with the required information to shade them such as the viewing direction). It's not really a hack and you can still use path tracing (with BSDFs) to correctly shade these points. In fact this is what Pixar did for Monster's University; they used the REYES algorithm to determine shading points visible from the camera and then shaded those using BSDFs and path tracing. The problem with this is that you basically have to store the scene twice: once for rasterization and once for ray tracing.

It's a bit unfair to compare the speed of Mitsuba with the speed of Renderman. Mitsuba only has a simple KD-Tree (although highly optimized), while RenderMan most likely has a state of the art BVH, which utilizes SIMD instructions. RenderMan also has a lot of sampling controls, while Mitsuba's path tracer has always traces one light and one BSDF sample on each intersection. There are multiple software engineers at Pixar that solely focus on optimizing RenderMan, while most of Mitsuba is implemented by a single person, who is a full-time researcher.

Mitsuba lacks a lot of features that are necessary for production: there is no proper support for hair (Mitsuba only has a simple Kajiya-Kay shader and no specialized acceleration structure for ray intersections), there is no support of subdivision surfaces, no support for displacement mapping, etc. All of these features are necessary in production.

Mitsuba is great for research though. It has support for a lot of experimental rendering algorithms (such as Metropolis Light Transport), which are not supported in production renderers. Due to Mitsuba's modular structure it's also incredibly easy to implement new algorithms, which makes Mitsuba a great framework for comparing rendering algorithms. A lot of papers use Mitsuba to compare their new algorithm to other algorithms.

Most production renderers use CPUs (just like Mitsuba). GPUs are incredibly powerful and some benchmarks show 400% speed improvements over CPU-based renderers. The problem is though is that GPU-based renderers struggle with the scenes that are used in production. Typical production scenes contain over 250GB of textures and over 10s of GBs of geometry (pre-tessellation). This isn't going to fit the in the memory of a GPU and the GPU will spend most of the time loading assets from the hard drive (or network).

ssize_t is not a part of the C++ standard, sadly.

Most courses offer just the syllabus without any slides or notes on the ACM digital library. There were many other great courses, but most sadly haven't posted their slides and notes yet.

Ask a random person if 1 and 0.999999... are the same number and most people will tell you they aren't the same number. Yet: 1 = 3 * (1/3) = 3 * 0.33333... = 0.99999... (they're also epsilon close for every epsilon larger than zero). So yes, this kind of stuff is surprising for a lot of people.

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.

Photon Mapping might be biased, but it's extremely easy to make it consistent by using the method outlined by Knaus and Zwicker [1]. Using that method photon mapping will converge to the right result. Even without progressive photon mapping you can choose a photon radius that won't cause visible errors.

[1] http://cgg.unibe.ch/publications/2011/progressive-photon-map...

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.

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 REYES algorithm isn't really the problem, you can just generate an acceleration structure and shade each shading point using ray tracing [1]. The REYES algorithm is just an algorithm that generates shading points and determines in which pixels those points are visible, it puts no restrictions on how you shade those points. The downside to mixing REYES and ray tracing is that you have to keep two representations of the geometry in memory, but that doesn't mean you can't combine the two.

The main problem with RenderMan before version 19 was that it didn't have a good acceleration structure and that you basically had to implement a path tracer in RSL on your own. Pixar wrote a path tracer in RSL for Monster's University, so Disney could have just used that. I doubt that they would write their own renderer if they could have just asked Pixar to implement a better acceleration structure in PRMan, so there were obviously different reasons too.

I think Ptex was an important reason for them to write their own renderer, as they seem to put a lot of focus on textures in their paper on the architecture of Hyperion [2]. Hyperion's architecture also allows them to use packet tracing and to load and subdivide geometry on demand, which is also really great.

[1] http://www.realtimerendering.com/resources/RTNews/html/rtnv1...

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

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.

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

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

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.