Quote - Thanks, PJZ. By "quality," I meant something like "intended accuracy." So a smaller number ought to be better quality by that definition, but artifacts make the render worse in actuality. That's how I'm interpreting your response. Right?

Actually, the conclusion I'm coming to is that the second Irradiance Cache slider is really the "intended accuracy" contol in a very direct manner - high quality to the right. (May be a problem somewhere above 90 and this bit needs some investigation.) From Stewer's comment earlier, it maps to "max error" inside the program. I believe that it is the reciprocal of ISS that is actually the max error. Hence, larger number are higher accuracy.

The magic of the Irradiance Cache algorithm works something like this: Shoot out a ray from the camera until it hits something. From that point in the scene, start sending out IDL Samples rays in random directions. Start with the first ray and follow it until it hits something, meanwhile remembering that we still have to do all the others. We'll eventually need the total light intensitiy at each of these points, but they are only potential evaluation points so far. Keep this up until we've run out of bounces on that first ray chain. This is going to be our first evaluation point. We send out one more bundle of IDL Samples rays. For these, when they hit, we trace back to the light sources, take the source light intensities and multiply them by the Diffuse color/value at each final ray's hit point, then average all the results from all the rays shot from the evaluation point. That gives us an estimate of the total amount of light arriving at the evaluation point, a.k.a. the irradiance at the evaluation point. Note that this evaluation point can be quite far from the point where the original camera ray hit.

But, wait! There's more! Since we have a bunch of samples in different directions at the evaluation point, we can weasle some more information out of them besides just the irradiance. Hairy math occurs at this point, but what comes out are numbers that allow us to calculate approximately what the irradiance is at points in the scene near to the evaluation point and, even better, how good that approximation is as a function of distance from the evaluation point. We store these numbers along with the location of the evaluation point and the irradiance in such a way that we can find them quickly given a nearby point in space. (Major Computer Science magic in that one.)

Whew. All that for the first ray shot from the last bounce from the first camera ray; only a bazillion more to go. It doesn't look promising on the render time front. But let's plow ahead. Let's assume, just so I'm not here all day, that the next final bounce lands pretty close to the evaluation point we already have recorded. We use the error estimator information from the evaluation point and the distance to the new, potential evaluation point so see if the estimate is good enough. The "max error" parameter is the definition of "good enough". If the estimate is good enough, we just use that and avoid sending out the last IDL Samples set of rays. If it is not good enough, we change the current point from a potential evaluation point to a real evaluation point, send out the last rays and record the new evaluation point's irradiance, approximation function and error estimate parameters.

If you think about that for awhile, taking breaks to let your brain cool down as appropriate, you'll see that in the early stages, nearly all potential evaluation points get turned into real evaluation points. But, despite my assumption in the paragraph above, these evaluation points typically get spread throughout the scene space and each of them carries a little ball inside of which it knows what the irradiance is. Eventually, and given the number of points we have to check this is certain to happen fairly early on, potential evaluation points start landing in these little balls and we get a fast answer.

Now, there is an even more subtle coolness that happens and you can see it best by watching where the little red dots apear. (Each red dot is a back projection into the camera of where a real evaluation point is.) It turns out that the error estimator at each evaluation point depends on the rate of change of the local geometry near that point; fast change means the error goes up fast with distance from the evaluation point. That means that in that neighborhood, more potential evaluation points will be converted to real evaluation points. You see that as the red dots crowding in around corners and the like where the geometry changes quickly.

I recommend playing with just the Samples and second Irradiance Sample Size for a while to get a feel for this.

Now, about the Irradiance Smaple Size. This is a heuristic (read "hack") to deal with the occasional cases where the complicated algorithm above goes wrong. Because the evaluation point error estimator is determined from random samples, sometimes you miss a critical sample that reveals an important change in local geometry. In that case, the error estmator says things are good at a given distance away when they are not. This leads to artifacts similar to "light leaks" - little places where the irradiance is clearly wrong. The hack is to apply an artificial upper bound on how far from an evaluation point any estimator is allowed to be valid. This adds more real evaluation points, but it does it everywhere, including places where the regular estimator would be perfectly fine. You can see this as a mesh of roughly evenly spaced red dots appearing when you decrease the Irradiance Sample Size. Most of the time, this is throwing away perfectly good cached values and your render time skyrockets. Personally, I'd try raising Samples significantly first to see if I can hit that critical geometry before lowering Irradiance Sample Size.

Summary: Keep Irradiance Sample Size as large as you can and apply it last. The second Irradiance Cache slider is the real quality parameter and your render-time friend. Set it as high as necessary, but no higher. Don't be too afraid of a lot of Samples; they are not used nearly as often as you might think and, since they're random, things get better only with the square root of Samples. 

Let's try that for a while and see how we do.

Whichway