Mael wrote:

> [..]
> > 1600 was chosen since it fits into a series 50,100,200,400,800,1600
> > very well.  Also, I figured that at some point someone would complain
> > about a big include file.
>
> interesting, thank you for the explanation. Does it mean that it's better to
> choose a value for count which has a factor of 50 ?
>

Short answer:  Yes, a little, maybe.
Long answer:  I admit I can't remember what number I used for "N"
in the annealing process.  I think it started at 50, but might have gone
up by more than 50 at some point after that (like 100 or 200, but also a
good chance I just doubled each time:  50, 100, 200, 400, 800, 1600).
It would only be a very small difference:  the points are known to be
very evenly distributed at each step up in count, because of the annealing.
Between those step points, you have the evenly distributed ones up to the
previous step, and a randomly selected subset of the ones making
up the next annealed set interspersed between them.
The difference between random and evenly distributed is very small,
especially at such high counts.
Numbers under 50 are bad, since they are not randomly distributed.
(this is working from memory from about 7 years ago...)
It is true that I always use a number from the series 50,100,200,400...


>
> > Note, if you have artifacts in a picture for which you want very high
> > quality output, it is 99% certainty that the problem is a bug in the
> > software (sorry) or the choice of other parameters, and <1% chance
> > you really need more samples.
>
> Some people were wondering why there were still some artifacts even for high
> counts, if you've managed to fix it this is really great news ! Thank you !
>

Well, I've got some of the bugs fixed.  I'm intent on making it at least
work as designed;  whether that's good enough or not, we'll see.
Based on Murphy's law, it will probably necessitate at least one change
to how it works as seen by the user, but I'll try to keep things
consistent for now.

>
> > Generally you want to aim for the goal of having each final sample
> > use an average of 20-ish old samples, but not from too far away.
> > Typically the existing released code achieves an average of about 2.
> > The number of rays in each old sample point is usually less significant
> > to the overall smoothness achieved.
>
> You mean the nearest_count should be 20 ? This seems quite a lot (the doc
> says the default value is 5), isn't there a risk to smooth too much the
> result ?
>

More smoothing is in fact what you want, provided you don't use samples
which are so far away that they didn't take into account objects which are
now close to you.  Generally, you want a very smooth
lighting effect on a simple plain.  There are two ways to get it.  Interpolate
very carefully between VERY accurate samples, or average lots of them, so
any minor errors are not visible.
There are big problems with the first (zillions of special cases that are
handled only approximately by this whole class of algorithm), so the second
is your best bet.  This is something that I never fully appreciated when I
first wrote the system.
The max *allowable* nearest count (MAX_NEAREST_COUNT in
radiotit.h) should be much higher, say 50.  (very few resources, there is only
one
structure which has an array of this size.  The code runs a linear scan through
these for each point reused, but with nearest_count=K, that's only <K/2
floating point compares each, which isn't much.)
The runtime max "nearest_count" default should be much higher than 5.
I've been trying numbers around 19-25 lately, and about 20 works best for
my current test scene.  (if points are on a hex grid, 19 would
equate to one point and all its neighbours within distance 2).

Another big problem is with discontinuities in the final trace.
Because of the desire for lots of old samples to average, and the desire
not to do any more samples (or very few) in the final trace pass, I
recommend a low-to-moderate error bound, a moderate trace count, and
a very low low_error_factor.  Try around 0.22  (roughly 1/sqrt(20)).
But be sure to add the fix (hack) for the ot_ins parameter of at least 5 or so,
since the tree gets traversed with the *final* error_bound on the last pass,
which will be 5 times bigger than during the earlier ones.
If you're using recursion >1, increase it by 1.4 for each additional depth too.

Note, if you like hacking and one an image to look a bit better, there's
another hack which helps a bit:  do the final rendering pass completely
twice.  Not as slow as you might think, since you're guaranteed not
to calculate any new radiosity samples.

But, I shouldn't be blathering about hacks, I should be off fixing the
bugs.

>
> I don't know if it's worth investigating but I've come across a paper
> (http://wfmh.org.pl/~thorgal/jatrac/papers/iccvg02-mskm-gradients.pdf)
> suggesting to take more sample locations according to local lightning
> distribution to improve Ward's original irradiance caching
>

I'll have a look at it.  In effect, the system already has some of this very
indirectly,
since it has many metrics of error which are used to estimate what the
nearby gradient should be, and increases its samples (decreases the
spacing beteween them) accordingly.  But the paper's abstract looks interesting,

I'll have a deeper look.
The existing system already calculates an estimate of rate of change of
illuminance in R, G, and B (dR/dx, dG/dx, dB/dx, dR/dx, dR/dy,...) at each
sample point (though not using Ward's method, the idea is the same).  Certainly
the
effective radius of a point could easily be further adjusted by increasing or
decreasing
the harmonic mean distance based on the local gradient being above or below
average.  Whether this would be an improvement or not, beats me.

Jim

Post a reply to this message