"clipka" <nomail@nomail> wrote:
> Did I ever mention that I *hate* POV 3.6 radiosity?
>
> Obviously it's the reference implementation POV 3.7 performance will be measured
> against.
>
> Less obviously, it's cheating like hell.
>
> For instance, at higher radiosity recursion depths, it simply "files" the
> radiosity samples under the wrong size in the octree, effectively "chopping"
> its area of influence from spherical (with a nice smooth gradient inward) to
> the octree node's cubic bounds (with a harsh "cutoff"). If we could see the
> scene as it "looks" at such recursion depths, it would probably appear awfully
> blocky and chunky.
>
> The code suggests that this was probably not done deliberately: It may well have
> been just another blunder, that just happens to speed things up at moderate
> recursion depths, because octree lookups will produce a smaller fraction of
> samples that turn out to be too far away and just waste time; at even higher
> depths, however, it gets so extreme that octree lookup returns only a small
> fraction of samples that would otherwise be re-used.
>
> Either way here I am, brooding over POV 3.7 radiosity performance, and coming to
> the conclusion that there's only one way to bring it back anywhere near what
> people have become accustomed to with 3.6:
>
> Cheat. Like hell.

I don't want to sound like a heretic...

It seems to me that there are still speed problems with
recursion_limit > 1.

My small idea: Is possible insert a keyword like *method* (as in "media") to
choose between radiosity_type_3.6 and radiosity_type_clipka (under
developement)?

Only a simple idea, if it is not too difficult to implement.
Clipka, a huge thank you for your efforts on the radiosity code.

--
Carlo

Post a reply to this message