There was a discussion, on p.a-u I think, around a year ago re even
distribution of stars. Original poster also had your problem.

Alf

Post a reply to this message

"Alf Peake" <alf### [at] peake42freeservecouk> wrote in message
news:3dac2984@news.povray.org...
> There was a discussion, on p.a-u I think, around a year ago re even
> distribution of stars. Original poster also had your problem.
>

Yeh - I vaguely remember (or another discussion on the same topic). A starfield
is an obvious candidate for running up against this issue.

Post a reply to this message

In article <3dac2bf2$1@news.povray.org>,
 "Tom Melly" <tom### [at] tomandlucouk> wrote:

> Yeh - I vaguely remember (or another discussion on the same topic). A 
> starfield is an obvious candidate for running up against this issue.

But...stars aren't evenly distributed. A random distribution would be 
closer to reality.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Christopher James Huff wrote:
> But...stars aren't evenly distributed. A random distribution would be 
> closer to reality.

An actual distribution of a few thousand would be even closer.  Hasn't
this already been covered in this group? ;)

-- 
Tim Cook
http://empyrean.scifi-fantasy.com
mirror: http://personal.lig.bellsouth.net/lig/z/9/z993126

-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GFA dpu- s: a?-- C++(++++) U P? L E--- W++(+++)>$
N++ o? K- w(+) O? M-(--) V? PS+(+++) PE(--) Y(--)
PGP-(--) t* 5++>+++++ X+ R* tv+ b++(+++) DI
D++(---) G(++) e*>++ h+ !r--- !y--
------END GEEK CODE BLOCK------

Post a reply to this message

hughes, b. wrote:
> Maybe this one from Mike Andrews last year might make some sense. Sure is
> confusing to me though.
> 
> news://povray.org/3B97457B.26C14AE4@reading.ac.uk

Hmm, that has the old calculation for the latitude - it was up to 2% off 
from the analytic function. I'll put in the updated version of the macro.

As for confusing ... well, maybe. The idea is to change the rate that 
you change the latitude while rotating about the y-axis at a constant rate.

The best function for the latitude is PH=180*(acos(1-2*F)/pi) where PH 
goes from 0 to 180 degrees as F goes from 0 to 1. This function covers 
the same area on the sphere surface for equal increases in F.

The best value to add to the rotation is the Golden Ratio, 
Phi=(sqrt(5)-1)/2, of the circle - so TH = mod(TH + 360*Phi, 360).

Hope this clears things up a bit.

Bye for now,
	Mike Andrews.

#macro Pack_Sphere (nSph, bigRad, smallRad, Offset, useSepTex, resetTh)
   #local Phi = (sqrt(5)-1)/2;

   #if (resetTh) #declare TH = 0; #end

   #local maxC = nSph;

   #if (smallRad < 0)
     #local Rad2 = -smallRad*2*bigRad/sqrt(maxC);
   #else
     #local Rad2 = smallRad;
   #end

   #local Rad1 = bigRad + Offset*Rad2;

   union {
     #local Count = 0; #while (Count < maxC)
       #local F = Count/(maxC-1);

       // the analytic function!
       #local PH = 180*(acos(1-2*F)/pi);

       #local P = vrotate(Rad1*y, <PH, TH, 0>);

       box { -Rad2, Rad2 translate P #if (useSepTex) sep_tex(TH, PH) #end }
       #declare TH = mod(TH + 360*Phi, 360);
     #local Count = Count + 1; #end
   }
#end

Post a reply to this message

"Christopher James Huff" <chr### [at] maccom> wrote in message
news:chr### [at] netplexaussieorg...

> But...stars aren't evenly distributed. A random distribution would be
> closer to reality.

I *think* you've misunderstood - it's avoiding the clumping of distribution
at the poles that I'm trying to avoid. Of course the random numbers are
evenly distributed - it's just that when you use them to rotate z, then y,
you tend to get clumping at the top and bottom.

Post a reply to this message

Tom & Lu Melly wrote:

> "Christopher James Huff" <chr### [at] maccom> wrote in message
> news:chr### [at] netplexaussieorg...
> 
>> But...stars aren't evenly distributed. A random distribution would be
>> closer to reality.
> 
> I *think* you've misunderstood - it's avoiding the clumping of
> distribution at the poles that I'm trying to avoid. Of course the random
> numbers are evenly distributed - it's just that when you use them to
> rotate z, then y, you tend to get clumping at the top and bottom.

Well, there's nothing that forces random numbers to be evenly distributed. 
It is probable that they more or less are, but nothin stops them from 
tightly clustered around one single point, for example. I think Chris meant 
a distribution where every point is as far away from other points as 
possible, so that the distances between points are roughly equal.

Post a reply to this message

The problem is really pretty simple.  Imagine putting the stars on a
cylinder instead, and you can see that the distribution would be more uniform.
At the poles, the space is "contracted" because the apparent number of locations
per unit area is much higher.  Think of dots printed on fabric, then gathered in
at the poles.  There will be far more stars where the fabric is gathered up.
    Conversely, imagine the stars printed uniformly on a rubber cylinder, then
stretched over a sphere- the equator will have far fewer than the poles because
the fabric is stretched out there.
    Now, to get rid of the gathering, my intuition says that all you must do it
use a squared radius function.  Imagine a centerline or axis through the sphere.
Any point on the sphere will be from zero to 1 radius from that axis.  So, to
make it more likely that you stars will appear near the equator and less so near
the poles, use the sine of the latitude and square it.  In fact, play with
exponents for the sine from 1 to 2 and you will find a value that will give you
what you want.
    That is the probability for a star appearing there if you write your
algorithm properly. Just multiply the square of the sine of the latitude by the
angle, or some similar idea.
    Time to get out the calculator and play around a bit.

Cheers!

Chip Shults
My robotics, space and CGI web page - http://home.cfl.rr.com/aichip

Post a reply to this message

In article <3db06ec0@news.povray.org>,
 Johannes Dahlstrom <sad### [at] tkukoulufi> wrote:

> Well, there's nothing that forces random numbers to be evenly distributed. 
> It is probable that they more or less are, but nothin stops them from 
> tightly clustered around one single point, for example. I think Chris meant 
> a distribution where every point is as far away from other points as 
> possible, so that the distances between points are roughly equal.

I meant that stars are not distributed so the angular distances between 
each one and the nearest neighbor as seen from earth are approximately 
equal. Stars are not "evenly distributed", they are closer to being 
"randomly distributed". I think that approximately matches what you 
said, but I'm not sure. ;-)

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Tom Melly wrote:
> 
> Okay, I'm trying to randomly distribute objects, using trace, on a sphere.
> 
> So, I do something like:
> 
> RotZ = 180*rand(R1)
> RotY = 360*rand(R1)
> Trans = transform(translate y*10 rotate z*RotZ rotate y*RotY)
> TVec = vtransform(<0,0,0>, Trans)
> Inter = trace(Ob, TVec, -TVec)
> 
> The trouble is that I end up with a bunching of objects at the poles for all the
> obvious reasons, so the question is, how do I best avoid this? 


You want something that's completely random, yet nonetheless
uniform in its randomness? (Or would that be random in its
uniformity?) It sounds a bit like Vroomfondel demanding 
"rigidly defined areas of doubt and uncertainty." ;-)

It seems to me there's two problems with the above: First, the 
random factor is given far too much weight -- it should be subtler 
if you want uniformity of coverage. Second, to avoid clumps, a 
periodic function weighted into a loop increment might help. This 
almost certainly isn't what you're looking for, but hopefully it 
will be of some use in whatever solution you eventually come up 
with...

#declare Sphere1 = sphere { <0,0,0> , 1 }
#declare R1 = seed(0);

#macro RR(Factor)
    #local X = (rand(R1)-.5)*Factor;
    X
#end //RR

#macro Spikey(TargetSphere,Density,sTexture)
    #declare Y=0; #declare X=0.1; //very_small, but not 0 
                                  //or we'll loop forever.
    #while (Y < 360)
        #while (X < 179.9) // 180-very_small, same reason. 
            #local Trans = transform {rotate<X+RR(5),Y+RR(5),0>}
            #local TVec = vtransform(<0,10,0>, Trans );
            #local I1 = trace(TargetSphere, <0,0,0>, TVec);
            #local I2 = I1 *1.5;
            cone { I1, .1, I2, 0 texture{sTexture} }
            #declare X=X+Density*sin(radians(X));
        #end //Y<360
        #declare Y=Y+Density; #declare X=.1; 
    #end //X<180

    // Cover the singularity left by very_small...
    #local I1 = trace(TargetSphere, <0,0,0>, <0,1,0>);
    #local I2 = I1 *1.5;
    cone { I1, .1, I2, 0 texture{sTexture} }
    #local I1 = trace(TargetSphere, <0,0,0>, <0,-1,0>);
    #local I2 = I1 *1.5;
    cone { I1, .1, I2, 0 texture{sTexture} }

#end//Spikey

Spikey(Sphere1,5,texture{pigment {rgb<0,0,1>} })



-- 
@C[$F];
The Silver Tome ::  http://www.silvertome.com 
"You may sing to my cat if you like..."

Post a reply to this message