Comment by solidangle | Hacker News Reader

Comment by solidangle | Hacker News Reader

Parent Full thread

AFAIK Industrial Light and Magic used Arnold for a lot of movies, Framestore used Arnold for Gravity (I'm not sure what they use now), Double Negative uses a whole range of renderers (with layer between their OSL shaders and the renderers) and Weta uses their own in-house renderer Manuka now. Most studios switched away from Renderman as its support for ray tracing was extremely lacking until a year ago. On your list of points:

* Bidirectional path tracing and VCM, surely is nice, but you're absolutely fine with just path tracing. Artists have learned how do to avoid SDS paths and how to optimize their scenes for path tracing. It would require a lot of time to train artists to optimize their scenes for VCM and with the amount of diffuse noise (which is unavoidable) I'm not even sure if it's worth it.

* I doubt the subsurface scattering in Cycles is slower than Renderman as it only supports bicubic and gaussian profiles which are even easier to evaluate and sample than the approximate BSSRDF ;). Their profiles are extremely lacking (and I doubt it's enough these days), but SPI used bicubics and gaussians a few years ago [1].

* I absolutely can't imagine that Cycles doesn't have Environment Map sampling, which is something pretty basic and explained in PBRT. Sure, Cycles probably doesn't have an implementation of "Portal-Masked Environment Map Sampling" by Bitterli, Novak and Jarosz yet, so I'm sure Renderman is better at it, but Cycles is decent at it.

* Same for arbitrary geometry lights, but I'm sure Renderman does a better job at it (although Pixar is probably limited by Solid Angle's patents on importance sampling quads and other stuff, Cycles doesn't have to deal with patents).

* AFAIK Cycles has a state of the art hair shader, but it seems to lack the importance sampling scheme by Eugene d'Eon.

I absolutely agree with you that Renderman is a more complete and faster renderer, but Cycles is absolutely amazing if you keep in mind that it was completely developed by a small team of hobbyists. Cycles isn't meant for production rendering, but it's amazing for hobbyists.

[1] http://dl.acm.org/citation.cfm?id=2504520

> * Bidirectional path tracing and VCM, surely is nice, but you're absolutely fine with just path tracing. Artists have learned how do to avoid SDS paths and how to optimize their scenes for path tracing. It would require a lot of time to train artists to optimize their scenes for VCM and with the amount of diffuse noise (which is unavoidable) I'm not even sure if it's worth it.

This is %100 not true. Forward path tracing is not adequate for anything except for direct illumination. Any enclosed space that has most of it's illumination from some sort of bounce is not feasible without some sort of illumination caching. Bidirectional path tracing and VCM do not carry any addition complexity from an artist's point of view. Also avoiding SDS paths is not always something that artists can simply avoid, and any illumination that is missing is room for improvement.

Do you have links to Solid Angle's patents? Renderman actually samples emissive geometry exceptionally well.

There are very few scenes that need Bi-directional or VCM (in VFX, anyway) - in theory it converges faster for indirect illumination, but due to the fact both methods need to be used in incremental mode (1 sample per pixel over the entire image), you significantly lose cache coherency for texture access (even for camera rays) as you're constantly trashing the texture cache, meaning renders are a lot slower. There are much better ways of reducing this indirect noise in production (portals, blockers).

On top of this, it's also very difficult to get the ray differentials correct when merging paths, so you end up point-sampling the textures, meaning huge amounts of texture IO.

So there are two different things there, bidirectional tracing without and with VCM. VCM takes longer to trace but takes care of outlier samples that can't be oversampled away in practice.

When it comes to any sort of bounce, forward raytracing is painful, anything that helps is good.

Most renderers don't take into account much cache coherency of textures at all, which makes me think you work for Disney?

Per iteration, bi-directional is extra work too. Obviously these integration methods are much better at finding certain hard-to-find light paths/sources, but my point is that in VFX, it's generally good enough to fake stuff by just turning shadow/transmission (depending on renderer) visibility off for certain objects to allow light through.

It's rare that we actually have glass/metal objects with lights in/around them such that bi-directional / VCM actually makes sense - even for stuff like eye caustics we've found that uni-directional does a pretty good job. And other situations like car headlights behind glass with metal reflectors behind the light, just turn transmission visibility off for the glass part, and yes, it's not fully-accurate (in terms of refraction and light leak lines), but we're generally using IES profiles for stuff like this so we get accurate light spread patterns anyway.

Well, they do in that camera rays generally (and light rays in bi-directional/VCM) end up using the higher mipmap levels of textures, so you're reading a lot more data for these samples, hence pushing stuff out of cache much more: we've seen this with PRMan 19/20 in RIS: using incremental can have a 3x slowdown in some cases compared to non-incremental, as the camera rays are much more coherent per-bucket in non-incremental, so the highest level mipmaps are kept in cache much more. With incremental, you're only sending the bucket size number of samples and equivalent texture reads for the camera rays, with secondary bounces generally using much smaller/lower mipmap tiles for the texture request (and you can get away with box filtering these in 95% of the cases), then moving on to the next bucket, which will probably need completely different high-level mipmap tiles for its camera rays. With texture IO often being the bottleneck in VFX rendering, this is a huge issue.

Nope, still in London for a bit, then off to NZ...

Hmmmmm.

So you're next in line to try to pull the sword from the Manuka stone?

Forward path tracing is what is used to render more than 95% of graphics you see in movies today. It's not great for closed spaces and VCM is better, but it's definitely possible to render everything with forward path tracing. People have been doing it for years, bidirectional methods have only started to get used in production very recently.

Forward path tracing with direct lighting only has been done for 'years' (about 4-5 years). Pure forward path tracing without caching of secondary illumination is being done now, but at great expense of render time and artist time to deal with the inevitable noise.

It is something that people are getting to work in the end but it is a consistently painful disaster.

So basically forward path tracing is not adequate. That doesn't mean it can't be forced to work through huge render farms, hacks, compositor painting and who knows what else.

I agree it's possible to do better than forward path tracing, but a big part of why nearly everyone switched to it was that it significantly reduces artist time, is a lot less painful and requires fewer hacks than the methods used before it.

The state of the art keeps improving but I've never heard any call the switch to forward path tracing a painful disaster, quite the opposite.

Few hacks yes, less painful I have to disagree with. It is the present and of course the future, but what I have seen is that the hacks shift to do anything possible to reduce noise, and the artist's time shifts to doing whatever they can do deal with noise. It never ends up being 'fire and forget' because renders end up either overkill on cpu time or with noise somewhere in the image.

Forward raytracing as it currently stands is awful to use at the moment on a large scale for final motioned blurred images that can be sold to a client, but because it is simpler it is still better than alternatives. That is because getting the same results out of (REYES) renderman was something left to a handful of gurus and fanatics.

Now we have a state where renders take 8 hours per frame per character per pass but people still like it better. So be it, but that is still very painful.

All fair points!

From your username, would you happen to be Marcos or someone else from Solid Angle? If so, big fan of Arnold. :)

Nope, sadly not. This username was one of the few computer graphics related usernames left on reddit and solid angle sampling is so much cooler than area sampling. You're not only person who thought this, so it's probably about time that I switch to a different username. I'm also a big fan of their work, though, I would love to work for that company once I'm done with university.

Btw, I also really enjoy reading your blog, keep up the good work. Looking forward to the day that you release the source of your renderer.

Reply on news.ycombinator.com