Warp <war### [at] tagpovrayorg> wrote:
>   Any chances of removing the upper limit of 1600 samples? While 1600 samples
> is a lot, some people have encountered the limit and complained about it.

Yes, definitely a chance to do that. However...

(1) I expect quality to improve even with less samples

(2) It's not so high on my agenda as, say, saving & reloading sample data

(3) It still takes some time to develop something good. i don't like the MegaPOV
approach of user-specified sampling sequences, and actually I don't like the
whole concept of a fixed sequence anyway. There must be a smart way to
implement some adaptive algorithm. I also think it would be a good idea to flag
objects as "radiosity targets", like it is done with photons, to inform the
sampling algorithm about small but bright objects so it can shoot a few more
rays in that direction.

>   Unless I'm mistaken, those samples are precalculated and hard-coded into
> the source. Removing the limit would probably mean that you need to calculate
> new samples (above those 1600) by using a random number generator. If you do
> so, the absolutely *don't* use rand() from <cstdlib>, but instead use a
> high-quality fast RNG designed for stochastic sampling.

Naah - speed is such an important issue with this that I'd rather precompute
directions like it is done now - although not at compile time, but at scene
startup instead.

If I'd need a RNG for that, I guess I'd use whatever is commonly used in POV
already. Speed is not really an issue for that job (nor is precision).

But I guess an even distribution is actually better than a random one for this
use.

Post a reply to this message