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