"clipka" <nomail@nomail> wrote:
> 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.

Another question, clipka. :-)
You think that is useful to work around a "count", like Megapov, to understand,
to offer the possibility *count > 1600* (with sample statement)?
Or you think that it is not necessary?


--
Carlo

Post a reply to this message