POV-Ray : Newsgroups : povray.programming : Radiosity code question #3 : Re: Radiosity code question #3 Server Time
28 Jul 2024 14:29:00 EDT (-0400)
  Re: Radiosity code question #3  
From: Jim McElhiney
Date: 25 Jun 2003 17:02:49
Message: <3EFA0DEB.453213FF@excite.com>
Christoph Hormann wrote:

> Jim McElhiney wrote:
> >
> > [...]
> > Not even sure how the POV team works these days,
> > i.e., who keeps the ball for making new official patches, or
> > (for that matter) whether or not anyone is interested in my bug fixes.
>
> In case of bug fixes i'm pretty sure the Team is interested in including
> them in the next official release (3.51).  If you have more elaborate
> changes this will be greatly appreciated for MegaPOV (3.51 is a bugfix
> release so there will be no new features).
>

I'll see whether I can work up changes that are small enough that
everyone will agree they're bug fixes.  (it becomes a judgment
call at some point!)

>
> While you are here - something that has wondered some of us lately is how
> the 1600 sample ray directions which are hardcoded in the program are
> originally generated.  There have been some affords to generate a better
> distribution (and the possibility to use more than 1600 rays).
>

The 1600 samples were created by a fairly sophisticated program
(given the apparent simplicity of the problem), which I might, or might
not, be able to find kicking around.  I spend MANY days on it.  (really!)
Basically, it tries to meet the following criteria:
- Lambert's cosine law.  i.e., for perfectly diffuse surfaces, contribution
for an angle rolls off as you go away from normal in a cosine fashion.
- Equal distribution axially.  (same around the circle).
- Evenly distributed spots, without a regular grid which could produce
aliasing.  Same idea as jittering, but hopefully better.
- Better than random or jittered distribution:  you want samples which are
(after taking into account Lambert) nearly equidistant, no matter how many
samples you have chosen.  Poisson disc is a good example.
- Good coverage at low angles.  I found a fairly naive implementation
did not manage this, and it caused nasty artifacts.  The reason is that
things close to the horizon do not contribute very much to the diffuse
interreflection coverage, but the points are also used for other things,
such as calculating the distance to the nearest object.  If you miss
a low-lying object...think of a pencil on a table, by itself in a very large
room...you get into big problems.  A point on the table surface a short
distance from the pencil will miss the pencil entirely, and end up with a very
large effective radius.  Therefore, its value will get used under the pencil,
which is bad--you should be using local values almost exclusively.  This is
also the reason I put in the distance_max feature--not a very elegant
solution.


So, the final method was:
1 - put the first few points into hand picked locations to handle
the horizon problem.  (first and second rows).  Fix them in place.
2 - spray N points onto the sphere  (e.g., N=50)
3 - use simulated annealing to move them around, so that they
repel each other (using the cosine weighting for the repulsive force).
Start with a very high temperature:  points can jump over each other.
4 - Fix those N points into place.
5  - repeat from step 2 till you hit the max you're going to support.

This means that, for any count which is an increment of N, the
points are pretty optimally distributed according to the chosen criteria.
If you build a POV file from the locations (using them as the centres
of small spheres, for example), you will see this effect.
Needless to say, the order in the file is significant.

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.

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.
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.

Hope this helps!
Jim


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.