Irradiance Caching

Ideas, enhancements, feature requests and development related discussion.

Irradiance Caching

Postby dcuny » Tue Jul 21, 2009 6:26 pm

One thing that bugged me about Inyo was that I never got irradiance caching to work. The other was that path tracing never quite worked right. So between the two, Inyo failed in its fundamental purpose: to be an open-source path tracer.

So I've decided to revisit the problem again. I found the book Practical Global Illumination with Irradiance Caching, which is fairly small (134 pages total), but the most in-depth book I've seen on the topic. I'm also revisiting a number of my other texts, to see if I can finally crack this nut.

It's been a long time since I've looked at Inyo, and I don't even remember if I've got a copy lying around which can be used without JPatch. Since the irradiance cache is independent of the renderer itself, I may just write a toy "spheres and plane" ray tracer to test it out with.

Unsurprisingly, the irradiance cache works equally well with accelerating ambient occlusion, so if I actually get this working, I'd more likely use this with ambient occlusion + spherical harmonics rather than a full patch tracing solution.

I didn't know this, but the Radience Renderer is now Open Source. The binary is available for a number of platforms. So (in theory) JPatch could support it.
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Re: Irradiance Caching

Postby dcuny » Mon Jul 27, 2009 8:41 am

I've run across an interesting paper on Irradiance Filtering. I'd seen it before, but never really paid attention to it. The authors argue that they can achieve the same results are irradiance caching, but at a much lower cost.

The paper notes that there's still artifact flickering with animations rendered using this technique, so it may be problematic. The approach looks a lot like the one outlined in the Pixar paper Statistical Acceleration for Animated Global Illumination.

Edit: On re-reading the paper, it doesn't look at all like the PIxar approach. But I'm still puzzling my way through the paper. I really wish I was better at math... :?

Edit: Corrected the link to the paper. :roll:
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Re: Irradiance Caching

Postby pndragon » Mon Jul 27, 2009 10:31 am

I really wish I was better at math...
There is no way that your math skills are as bad as mine.
"We're so sorry, Uncle Albert,
But we haven't done a bloody thing all day."
--- Paul McCartney
pndragon
 
Posts: 591
Joined: Sun Dec 05, 2004 1:27 am
Location: North Carolina

Re: Irradiance Caching

Postby sascha » Mon Jul 27, 2009 5:17 pm

The link to the paper actually links to a video :wink:
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Re: Irradiance Caching

Postby dcuny » Mon Jul 27, 2009 9:30 pm

sascha wrote:The link to the paper actually links to a video

Ooops! In my defense, it's a good game. ;)

I'm having trouble grokking the technique in the paper. The technique of irradiance caching is pretty straight forward: you use surrounding samples and average an irradiance estimate. This allows you to amortize high-quality sampling over many pixels.

From what gather, the Arnold renderer used a slightly different technique. It would perform high-quality sampling (i.e.: 256+ rays) in screen space (say, every 8x8 pixel), and then interpolate a value for intervening pixels. It would then perform a lower quality (i.e.: 32+rays) and compare the estimate with the approximation. If there was too much variance, it would instead use a high-quality sample.

I get the general idea of filtering, but I'm just fuzzy on the specifics. It'll probably take me a couple of days of carefully reading through the paper until I finally really understand what's going on. One other bit of concern is a general lack of references on the Internet. If a method is really that much better than another, you'd thing people would be adopting it. There's also this, which says:
Irradiance computation is done using an irradiance cache instead of using the irradiance filtering algorithm.
It makes me wonder if this method is ultimately a dead end. :?
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Re: Irradiance Caching

Postby sascha » Tue Jul 28, 2009 10:54 am

I still wonder if Ambient Occlusion isn't sufficient for animation. It's fast, and you've got a great deal of control over the final look (and no noise!)
So, for the cartoon-style I have in mind I think using raytracing for reflections and possibly shadows, AO for global illumination and good old REYES for everything else is the way to go. 3Delight seems to deliver all of that, and it's just a matter of time until the open source renderers will catch up.

Pixar and many other studios clearly aim for more photorealism in every new film, but I don't think that this leads to better films. Ok, if you look at Toy story today, the rendering (not the animation) looks a bit dated, but since Monsters the image quality is gorgeous. Adding more photorealism is cool and sets the mark for everybody else, but otherwise isn't necessary in any way.
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Re: Irradiance Caching

Postby dcuny » Tue Jul 28, 2009 6:23 pm

sascha wrote:I still wonder if Ambient Occlusion isn't sufficient for animation. It's fast, and you've got a great deal of control over the final look (and no noise!)

I'd add to that some sort of image based lighting as well. But yes, that pretty much covers the gamut.

So, for the cartoon-style I have in mind I think using ray tracing for reflections and possibly shadows, AO for global illumination and good old REYES for everything else is the way to go. 3Delight seems to deliver all of that, and it's just a matter of time until the open source renderers will catch up.

I think targeting 3Delight as the renderer of choice for JPatch is a good idea.

I'm rather disappointed that Marin is relatively slow rendering simple scenes. It's currently in the "pretty much abandoned" state, but I'm sure that at some point in the future I'll have the urge to revisit it. Supporting JPatch, for example, would probably provide a bit of motivation. ;)

It was a real pain for me to get approximate occlusion working for my OpenGL renderer, but I've still got the code laying around. The approach in Blender is complicated a bit because it takes the approach outlined in GPU Gems 3 and ultimately resolves down to triangle-based geometry. This doesn't happen with the point cloud approach, so it might be a bit easier to implement. :?

Interestingly, the pixel cache in Blender approximate ambient occlusion seems to be a plain vanilla screen-based interpolation, rather than some fancy irradiance cache. :|

Ok, if you look at Toy story today, the rendering (not the animation) looks a bit dated, but since Monsters the image quality is gorgeous.

That's apparently one of the reasons they decided they decided to go back and re-render Toy Story. According to Wikipedia, Toy Story was rendered at 1536 × 922 (1.42MP). The time to render one frame was typically around 2–3 hours, with ten times that for the most complex scenes. According to this link, the average frame from Cars took 15 hours, despite a 300x overall increase in compute power.

The big complaint of the Reyes architecture is that it never really accounted for global illumination. The strength of Reyes - that you dice geometry down to the needed resolution - was also the big problem when dealing with GI. I think point-based occlusion takes care of a lot of this. Still, most studios seem to be going with a dual ray tracer architecture, because it allows single or multiple bounce lighting effects. You can simulate this with approximate ambient occlusion, but it doesn't seem to be happening with commercial studios.

Despite approximate ambient occlusion, you'll note that Pixar seems to be doing more and more ray tracing these days. Then again, they have the hardware to back it up- and they can afford huge render times!

Of course, having to essentially maintain two different renderers is a pain. Blue Sky seems to be the only studio using a pure ray tracing solution. The real problem with a ray tracer is holding a massive amount of geometry in memory.
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am