Projecting the disk onto the hemisphere requires "blowing up" the set of
samples in order to prevent samples "sticking" nearby the edge of the
sphere/disk. The surface near the center of the disk grows more than the
surface near the edge, so near the center the samples move farther away.
That results in an uneven distribution.

Post a reply to this message

Apache wrote:
> IS MY DISTRIBUTION CORRECT?

When viewed from above (+z), a cos theta distribution should look like
uniformly spaced points on a disc. (This isn't hard to show with a little
math.) But neither of your +z views look that way.

Anders

--
#macro E(D)(#if(D<2)D#else#declare I=I+1;mod(pow(.5mod(I 6))*asc(substr(
"X0(1X([\\&Q@TV'YDGU`3F(-V[6Y4aL4XFUTD#N#F8\\A+F1BFO4`#bJN61EM8PFSbFA?C"
I/6 1))2)<1#end)#end#macro R(D,I,T,X,Y)#if(E(D))R(D-1I,T,Y/2X)R(D-1I,T+Y
/2Y/2X)#else box{T T+X+Y pigment{rgb E(2)*9}}#end#end R(10,5z*3-1v*2u*2)

Post a reply to this message

> Projecting the disk onto the hemisphere requires "blowing up" the set of
> samples in order to prevent samples "sticking" nearby the edge of the
> sphere/disk. The surface near the center of the disk grows more than the
> surface near the edge, so near the center the samples move farther away.
> That results in an uneven distribution.

I'm not sure your understood the projection
sample points evenly on disc (x,y)
then build (x,y,z) with same x,y and z=sqrt(x*x+y*y)
(and we do want an uneven distribution with more points near the center)

M

Post a reply to this message

The set that POV-Ray uses currently doesn't look like that either. (see my
post, pbi "Re: >1600 radiosity samples: right costheta distribution?"). "My"
distribution has very similar properties to that of POV-Ray, except for the
ordering that I still have to fix.

Post a reply to this message

Apache wrote:
> 
> The set that POV-Ray uses currently doesn't look like that either. (see my
> post, pbi "Re: >1600 radiosity samples: right costheta distribution?").

You are obviously doing something wrong, i just rendered it and it look
totally different here (it looks indeed uniform although not extremly high
quality).

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

I'm nuts .......    I rerendered it and it turned out to be some perspective
distortion :-)

Post a reply to this message

"Apache" <apa### [at] yahoocom> wrote in
news:3e16ad01$1@news.povray.org 

[...]

Maybe just make a scene that needs >1600 samples, build i.e. 5000 samples 
array, re-compile POV and make few renders involwing old and new 
distribution

-- 
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M

Post a reply to this message

"Nathan Kopp" <pov### [at] nkoppmailshellcom> wrote in
news:3e1714cf$1@news.povray.org 

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

Why not generate array of arrays ?
array for count=3, count=4, count=5 etc... ?

taht would be much faster then generating in real-time, and will not use to 
much memory


-- 
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M

Post a reply to this message

Rafal 'Raf256' Maj wrote:
> Why not generate array of arrays ?
> array for count=3, count=4, count=5 etc... ?
>
> taht would be much faster then generating in real-time, and will not use
to
> much memory

Uh, it won't? Just the tables for up to 1600 samples would require 3.7 MB in
packed format, and we want to go well beyond that!

Anders

--
#macro E(D)(#if(D<2)D#else#declare I=I+1;mod(pow(.5mod(I 6))*asc(substr(
"X0(1X([\\&Q@TV'YDGU`3F(-V[6Y4aL4XFUTD#N#F8\\A+F1BFO4`#bJN61EM8PFSbFA?C"
I/6 1))2)<1#end)#end#macro R(D,I,T,X,Y)#if(E(D))R(D-1I,T,Y/2X)R(D-1I,T+Y
/2Y/2X)#else box{T T+X+Y pigment{rgb E(2)*9}}#end#end R(10,5z*3-1v*2u*2)

Post a reply to this message

And that's exactly what I'm planning on.

Post a reply to this message

That's exactly what came to my mind, too.

I tweaked my old sunflower-testscene to generate the points on
a hemisphere like Mael described in his post.

I quite like how it came out. It looks evenly distributed when viewed
from above with orthographic view and it scales good with increasing
number of points.

I posted the anims in p.b.a
comments are welcome,

Thies

Post a reply to this message

My box is currently calculating a set of 6400 samples. It seems it will take
quite some time, but whenever it's finished, I'll let you know.

The ordering is very good, so with very low samples the distribution is very
good. If the count is set to 6400, the distribution is equal to the golden
ration distribution. (See Thies Heidecke's post in this conversation.)


Regards,
Apache

Post a reply to this message

Apache wrote:
> 
> My box is currently calculating a set of 6400 samples. It seems it will take
> quite some time, but whenever it's finished, I'll let you know.
> 
> The ordering is very good, so with very low samples the distribution is very
> good. If the count is set to 6400, the distribution is equal to the golden
> ration distribution. (See Thies Heidecke's post in this conversation.)

You should note that this is a regular distribution, therefore will be
likely to generate regular artefacts under certain circumstances.  Using
regular distributions has been tried before, see for example:

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

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

I found out the distribution isn't as good as I thought. I think the problem
is in the ordering, which is more complicated than I had expected  ;-)

Post a reply to this message

"Anders K." <and### [at] kaseorgcom> wrote in
news:3e1744a3$1@news.povray.org 

> Rafal 'Raf256' Maj wrote:
>> much memory
> Uh, it won't? Just the tables for up to 1600 samples would require 3.7
> MB in packed format, and we want to go well beyond that!

MB or KB ? I thought that each record is 3 doubles ?
3*4*8*1600 = 150 kB

3*4*8*1600*1600/2 = 117 MB for array like :
(x), // count=1
(x,x), // count=2
(x,x,x), // count=3
//...
(x,x,x,x,x.....) // count = 1600

117 MB is too big in fact... so maybe generate only support every 10-th 
copunt above 300 ?
so count can be : 1,2,3...299,300, 310,320,330...
and every 20-th >600 600,620,640...
in that way array for count=3000 could be about hmm 50 MB i estimate ?

It can be downloaded as separate file from ftp://


-- 
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M

Post a reply to this message

Rafal 'Raf256' Maj <raf### [at] raf256com> wrote:
> in that way array for count=3000 could be about hmm 50 MB i estimate ?

  I don't feel quite comfortable with the program taking so much memory
just for a huge table.
  Perhaps a better (and more memory-saving) method should be developed?

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

> then build (x,y,z) with same x,y and z=sqrt(x*x+y*y)

hmm sorry, the correct is z=sqrt(1-x*x-y*y)
I tried it for the halton distribution (see on
http://195.221.122.126/samples/samples.html)

M

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote in news:3e18c7a4@news.povray.org

>   I don't feel quite comfortable with the program taking so much memory
> just for a huge table.
>   Perhaps a better (and more memory-saving) method should be developed?

How about allowing only some fixed count numbers, like : 

1..50 increment by 1 - 1,2,3
50..100 inc by 10 - 50,60,70
100,300 inc by 20
300..1000 inc by 50
1000..5000 inc by 200


-- 
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M

Post a reply to this message

Rafal 'Raf256' Maj <raf### [at] raf256com> wrote:
> How about allowing only some fixed count numbers

  That sounds more like a kludge than a solution. :)

  I was thinking more like storing only some of the points and interpolating
the rest on the fly or whatever.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote in news:3e19863d@news.povray.org

>> How about allowing only some fixed count numbers
>   That sounds more like a kludge than a solution. :)

but why :) ? I realy doubt if someone will see difference beetween
1043 and 1044 conut...



-- 
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M

Post a reply to this message

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

I do not think that would be a good measurement. In the following
example, the distance to the nearest neighbour is EQUAL for all points
(it is always 1 because the points are paired), while I expect you to
agree
that this is not a good distribution. (The example fills a rectangle,
not a
hemisphere, but that is irrelevant.)

   +----------------------------------------+
   |      *                                 |
   |  **  * *                               |
   |        *  **                           |
   | **                                     |
   |     *   **                             |
   |     *                                  |
   | **     **                              |
   |    **                                  |
   |  *    **                               |
   |  *                                     |
   |                                        |
   |                                        |
   |                                        |
   |                                        |
   |                                        |
   |                                        |
   |                                        |
   |                                        |
   |                                        |
   |                                        |
   +----------------------------------------+

Even if you ,,disallow'' the unevenness depicted here, you are bound
to get grid artefacts, which can be a real killer, if the sample grid
interacts with some object grid in the scene in a moir'e way.

Proposal for quality measurement: Density. Given a subset A of the
space you want to fill, the density is the quotient of the number of
samples inside A and the size (here: area) of A. The density should
not differ much for different A. As we intend a discrete distribution,
we have to restrict the quality measurement to A of a suitable minimum
size.

  Mark

Post a reply to this message

Mark Weyer wrote:
> 
> > 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).
> 
> I do not think that would be a good measurement. In the following
> example, the distance to the nearest neighbour is EQUAL for all points
> (it is always 1 because the points are paired), while I expect you to
> agree
> that this is not a good distribution. (The example fills a rectangle,
> not a
> hemisphere, but that is irrelevant.)
> 
> [...]

You are right, this is not a very good measurement.  None the less with
some change it is suited for comparing distributions.  From all
distributions with N points the one with the largest minimum distance
between two points could be considered as the best.  

A different measurement would be calculating the sum of the inverse
distances of every point to all other points.  All this sums together
should be low for a good distribution.

> 
> Proposal for quality measurement: Density. Given a subset A of the
> space you want to fill, the density is the quotient of the number of
> samples inside A and the size (here: area) of A. The density should
> not differ much for different A. As we intend a discrete distribution,
> we have to restrict the quality measurement to A of a suitable minimum
> size.

The problem is that this would not detect anisotropy.  

One important point about radiosity sampling is that the mathematically
best distribution is not necessarily the best for high quality radiosity
results.  As you already mentioned regularity artefacts are a major
problem.  The halton distribution Mael implemented seems to work quite
well at high count values although it is surely not the best in terms of
mathematical quality measurements.  

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

> You are right, this is not a very good measurement.  None the less with
> some change it is suited for comparing distributions.  From all
> distributions with N points the one with the largest minimum distance
> between two points could be considered as the best.

Without having tried I would suspect this to favor grids.

> A different measurement would be calculating the sum of the inverse
> distances of every point to all other points.  All this sums together
> should be low for a good distribution.

Another aspect are boundary effects. Take, for simplicity, a
one-dimensional
example: 4 points in the unit interval. In the optimum one point will be
at 0
and another at one. Because of symmetry the other two will be at x and
1-x.
The function you want to minimze then is 4/x+4/(1-x)+2/(1-2x). The
optimum
due to common sense is x=1/3 while this does not minimize the function:
Its derivative at 1/3 is 9, while it would be 0 at the minimum.

This does not matter though, if the distribution is calculated on a
boundary-less space, such as a torus, and then mapped to the space we
are interested in.

> The problem is that this would not detect anisotropy.

What is anisotropy?

  Mark

Post a reply to this message

> >> How about allowing only some fixed count numbers
> >   That sounds more like a kludge than a solution. :)
>
> but why :) ? I realy doubt if someone will see difference beetween
> 1043 and 1044 conut...

Ive done such tables in my renderer, storing normal coordinates in float format (not
the double).

Made tables from 4 (4x4) to 32 (32x32) [ as you can see Ive iterated through N
generating NxN samples) and it occupies much less
space

Tabulated ray directions were calculated by computer simulated annealing.
A few variants of distributions: uniform, pure cosine and a few variants of
degenerated BRDFs.
Each variant occupies something like 140KB for full series of samples 4x4, 5x5,...
32x32.

Samples were distributed perfectly, leaving some place to add some noise ("perfect"
Poisson discs).

There is really no need for having tables for 4,5,6,7,8.....4096 samples, just because
from Monte Carlo theorem of reconstruction  2-times increase in samples lowers the
noise sqrt(2).

Post a reply to this message