I'm working on some C code that generates radiosity sample data. I want to
have more than 1600 samples available. I have posted an image at pbi that
I'm referring to in this post.

Firstly, this piece of code creates a random distribution on a sphere
(without bunches near the pole):

/*---------code snippet----------*/
#define RANDOMVALUE     ((float)rand()/(float)(RAND_MAX))
  for (i = 0; i < SAMPLESAMOUNT; i1++) {
    float costheta = RANDOMVALUE*2-1;     // -1 <= costheta <= 1
    float phi = 2 * PI * RANDOMVALUE;     // 0 <= phi <= 2*pi
    float squareroot = sqrt(1-costheta*costheta);

    x[i1] = cos(phi) * squareroot;
    y[i1] = sin(phi) * squareroot;
    z[i1] = costheta;
  }
/*----------end of code snippet-------*/

Secondly I have some code that moves the samples a bit around in order to
divide the samples more evenly. This way there won't be local gaps or
bunches in the distribution. The resulting distribution is visible in the
upper row (part A and B at pbi).

After that I have moved the samples again with this piece of code:

/*----------code snippet---------*/
  for (i = 0; i < SAMPLESAMOUNT; i++) {
    float phi   = .5 * PI;
    float theta   = .5 * PI;
    float q       = sqrt(x[i]*x[i]+y[i]*y[i]);

    if (x[i1] != 0) { phi = atan(y[i1]/x[i]); }
    if (x[i1] < 0) { phi = PI + alpha; }
    if (q != 0) { theta = atan(z[i]/q); }

    theta = PI*.5*sqrt(theta/(PI*.5));  //this line actually moves the
samples

    x[i] = cos(phi)*cos(theta);
    y[i] = sin(phi)*cos(theta);
    z[i] = sin(theta);
  }
/*----------end of code snippet--------*/

Finally I order the samples and write them to disk (see C and D in the image
at pbi). By ordering them, the set also is distributed the right way when
only the first few samples are being used. (Think of count 35 etc etc etc.)


Additional graphs:
E: statistical data derived from the 1600 samples from POV-Ray 3.5
F: the properties of the data generated by my code.


And now my question:
IS MY DISTRIBUTION CORRECT?
I'm wondering this because the pink line (x*x+z*z) in part E of the picture
isn't completely straight. Especially the second half at the upper right
(sample 1000 and higher) is bent.



Regards,
Apache

Post a reply to this message

Apache wrote:
> 
> [...]
> 
> And now my question:
> IS MY DISTRIBUTION CORRECT?
> I'm wondering this because the pink line (x*x+z*z) in part E of the picture
> isn't completely straight. Especially the second half at the upper right
> (sample 1000 and higher) is bent.

First of all there is no 'correct' distribution, you can only try to
measure the quality of your sample set and compare it to others.  One
measurement of quality would be to measure the distance of each point to
its nearest neighbor - if this is very similar for all samples the
distribution is quite good (a non uniform distribution is more difficult
of course).

The images in p.b.i don't tell much.  First of all the side views don't
hide the back side so you can't see how evenly the samples are
distributed.  The 'A' picture looks quite good but a view from above does
not tell that much.  Also i don't understand the diagrams at all, what do
they show?

BTW 'cos theta' distribution means the density of samples is proportional
to the angle to the normal vector.  This will result in a quite uniform
appearance when viewed from above.  Your 'C' sample does not look like
that.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 31 Dec. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

Doesn't really matter anymore, because I'm already pretty sure that the
thing works correctly. I'll post a new rad_data.cpp with a larger set of
samples shortly.

Post a reply to this message

> IS MY DISTRIBUTION CORRECT?

I think the C distribution does not correspond to the existing rad_data. If
you want to verify, take your 1600 samples, compute their theta, and draw a
frequency graph
You can try this :
create a regular distribution in a disc, move your points evenly (how to you
do that part by the way ?), then just project the disc on the hemisphere,
and voila

M

Post a reply to this message

Maybe this might interest you : 2 years ago, Stephane Marty (who
created Virtualight) issued a POV-Ray patch whoch allowed users
to select amongst 8 samples distribution shemes for radiosity.

http://perso.wanadoo.fr/albedo/patchedpov.html

If you download and read the HTML docs, you will see samples
of the availiable distributions.

Fabien.

Post a reply to this message

Probably coincidence but 1st glance at "C" reminded me of the spirals
you get in the Golden-Ratio involving (sqrt(5)-1)/2.

Alf

Post a reply to this message

"Apache" <apa### [at] yahoocom> wrote...
> I'm working on some C code that generates radiosity sample data. I want to
> have more than 1600 samples available. I have posted an image at pbi that
> I'm referring to in this post.
[clip]
> Finally I order the samples and write them to disk (see C and D in the
image
> at pbi). By ordering them, the set also is distributed the right way when
> only the first few samples are being used. (Think of count 35 etc etc
etc.)

The code you posted looks like it is on the order of O(n), unless the code
you posted is missing a "for" loop (maybe on the variable "i1").  I would
have expected the code that "moves the samples a bit around in order to
divide the samples more evenly" to be at least O(n^2).

If it realy is O(n), which would be great, couldn't you simply generate an
appropriate distribution each time, removing the need to order them.  If the
algorithm produces evenly spaced samples for small counts, this would also
ensure that small sample counts look their best.

-Nathan

Post a reply to this message

The cod that I posted is O(n), and the code that "moves the samples a bit
around" is O(n^2) indeed. And so is the code that orders the stuff. However,
I'm still trying to get a better ordering. Or I could precalculate tons of
sets for count 1, count 2, ..., count 3199, count 3200. It takes some time
and space, but renderings with low counts will have less artifacts then.
Let's say that a*quality+b*resources-c=0  :-)

Post a reply to this message

> I'm still trying to get a better ordering. Or I could precalculate tons of
> sets for count 1, count 2, ..., count 3199, count 3200. It takes some time
> and space, but renderings with low counts will have less artifacts then.
 Oh, that won't work out as I thought is would, because in many cases
POV-Ray doesn't use as much samples as it is told to do with count when
there are more errors allowed. So every set has to be ordered anyhow. But I
still think that seperate sets can decrease artifacts.

Post a reply to this message

I was thinking the same.

Post a reply to this message