Ah, yeeeees!

Now with some good deal of *systematic* (and well-documented) cheating, it looks
like we're closing back in on POV 3.6 performance, at the same quality, minus
some of the artifacts, and minus the ugliness of the code...

Maybe there's even more to gain here.

The key to success turns out to be in the sample cache performance, regarding
"false positives" (samples returned by cache lookup but found unsuitable for
re-use due to various geometric reasons) vs. "false negatives" (samples that
could be re-used but aren't found by cache lookup).

Obviously, "false negatives" are costly, because they cause additional samples
to be taken when actually there's enough around already - and, as we all know,
taking samples is the most expensive thing about radiosity.

Wrong.

As it seems, "false positives" are actually much worse. Sure, processing a
sample returned by cache lookup just to find out that it cannot be used right
here after all - due to scene geometry issues - costs a good deal less than
taking another sample. But it typically happens something like 5,000 times more
often!

So why not tune the whole radiosity process a good deal towards "false
negatives" instead of "false positives"? The answer is one single word:

Artifacts!

For a perfectly artifact-free shot, you need a *zero* "false negatives" approach
- otherwise it is impossible to properly "blur" the samples together, and
instead hard "cutoffs" are seen at the boundaries between octree cells. You
don't want that. We've seen exactly that happening in beta.29 and earlier.

The good news, however, is that it doesn't matter that much for deeper recursion
levels: Artifacts at that level are only "seen" by the radiosity algorithm
itself - which has a very blurry vision by design.

So obviously this is the way to go - not in a seemingly haphazard fashion like
3.6, but a controlled one, allowing even for a much better tuning.


So, what's the bottom line of all this? Well, noting actually - just spreading
my enthusiasm about getting radiosity back to full gear.

We can't expect identical performance behavior as in 3.6 for all scenes - but on
average it seems to be a close match what I have here right now. I'll try some
more tweaking to see if it can even be improved.

Post a reply to this message