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.

Post a reply to this message

clipka <nomail@nomail> wrote:
> Cheat. Like hell.

  Well, if it looks good, who cares?

-- 
                                                          - Warp

Post a reply to this message

"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

"Carlo C." <nomail@nomail> wrote:
> I don't want to sound like a heretic...
>
> It seems to me that there are still speed problems with
> recursion_limit > 1.

That's why I'm still fighting with the whole smash :P

I've been fighting these ever since I submitted the code for beta.29-rad, and
haven't checked in any substantial changes since then. I just haven't been able
to come up with something I'd put a "probably stable" label on.

The beta.29-rad code did deserve that label, because it has the nice property of
being ridden of each end every of those uglies inherited from the 3.6 code.

Unfortunately, some seem to have been not bugs but undocumented features; so
here I'm stuck with the more exhaustive job of sifting through all the shit to
find some grains of sand in it, so to speak.


As of now, I'm back at MegaPOV 1.2.1 performance (speaking of CPU time) on an
64-bit AMD QuadCore Linux system for the majority of my portfolio of
benchmarking scenes (plus/minus roughly 10%), with an occasional scene taking
up to 61% more CPU time - except for recursion_limit > 1 scenes with a
significant amount of reflection, which may need up to 470% more processing
power (thanks to Cermak for providing the meanest radiosity test scenes I've
seen so far :P).

I'm not happy with this yet: To achieve this, the radiosity sample cache octree
is degenerated into not much more than a voxel tree at recursion levels 2 and
above - in a rather uncontrolled fashion. I'd be more happier with a
straightforward, honest "forget about spheres of influence and gradient, now
we're going for hard-cutoff cubes" approach. And I've yet to identify why
reflections behave that bad.


> 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)?

Yuck. 3.6 didn't just cheat - it also had a host of outright design errors.

I'm positively *not* reviving 3.6 radiosity. Maybe re-introducing some of the
cheats, that's all. In a more systematic, straightforward, well-documented
fashion. To let future generations know right from the start that it's *not* a
bug.


> Clipka, a huge thank you for your efforts on the radiosity code.

You're welcome (*walks off still grumbling*)

Post a reply to this message

clipka wrote:
> Yuck. 3.6 didn't just cheat - it also had a host of outright design errors.
> 
> I'm positively *not* reviving 3.6 radiosity. Maybe re-introducing some of the
> cheats, that's all. In a more systematic, straightforward, well-documented
> fashion. To let future generations know right from the start that it's *not* a
> bug.

Oh, welcome to the club! How often did I have to go down that road with 
various patches that made it into 3.5 :-(  And if you are looking for 
something else to wonder about, there are some media sampling shortcuts I 
did never find the time to fix in 3.7 - although I did try some fixes that 
ultimately did not work because they also missed some tricks in the code.

	Thorsten, POV-Team

Post a reply to this message