"nemesis" <nam### [at] gmailcom> wrote:
> "clipka" <nomail@nomail> wrote:
> > It seems that 3.6.1c is somewhat closer to the "real thing" in general - but
> > that for some reasons it gives exceptionally bad results on the left side of
> > the pedestal's top.
>
> What bad results?  You're talking about (a), right?

No, to me (a) looks more realistic than all the others - I'm talking about (b).
And from the process of how it was generated, I must assume that it took more
samples than the others.

> > This also shows that 3.6.1 radiosity is far from perfect
>
> Why?

'cuz it gives you significantly different results depending on whether you save
and later re-load the whole smash. Taking some more samples should reduce
artifacts, but not change anything dramatically.

> And, hey, while you're messing around with it, how about getting
> radiosity "count" limit way up? ;)

Not so high on my agenda. It's a bit "tricksy" anyway: It's not like POV-ray
would just shoot so many random rays - in that case there wouldn't be any
reason for the "hard deck" of 1600 samples. Instead, POV-ray picks the first N
rays from a hard-coded sequence of 1600 sampling directions.

MegaPOV has a mechanism to supply your own sampling directions, and thereby
overcome that limitation. But I'd rather go for figuring out how the original
sampling directions were chosen, and implement an algorithm that re-computes
the very same sequence when POV initializes the radiosity code. Or a larger
one.

Using truly random directions is not an option, because producing (pseudo-)
random numbers is a comparatively costly thing, converting them to suitably
distributed directions requires a bit of trigonometric functions (highly
costly!), and would actually need a higher count to get the same quality.

An interesting side note though: Did you know that you actually don't get the
specified count for all your samples? Instead, the effective count decreases
drastically with trace depth. In fact all your quality settings do.

Post a reply to this message