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? I assume it's
something like:
ZRotFac = 1 + pow(abs((ZRot/90)-1),2);
ZRot = ZRot * ZRotFac

But,

a) is this correct? (well, it's not, afaik - the range 1..2 is too limited imho)
b) if not, what is?

--
#macro A(V,B,C,R)#while(B-256)#if(V-128/B>=0)sphere{0,.5translate<C-4R-1,9>
pigment{rgb<1-C/8R/2C/8>}}#local V=V-128/B;#end#local B=B*2;#local C=C+1;#
end#end A(234,1,0,2)A(85,1,0,1)A(81,1,0,0)light_source{-5 1}//Tom Melly

Post a reply to this message

I've come across the same problem some time ago,
so I implemented a macro which calculated an
electrostatic-repulsion algorithm. Some animations of
this macro can be found on my website.

If you want the code, I can see if I have to clean
the code a little or if I can send it to you right
away, just give me an email-adress.

Regards,
Tim


--
Tim Nikias
Homepage: http://www.digitaltwilight.de/no_lights/index.html
Email: Tim### [at] gmxde

> 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? I assume
it's
> something like:
> ZRotFac = 1 + pow(abs((ZRot/90)-1),2);
> ZRot = ZRot * ZRotFac
>
> But,
>
> a) is this correct? (well, it's not, afaik - the range 1..2 is too limited
imho)
> b) if not, what is?
>

Post a reply to this message

On Tue, 15 Oct 2002 12:03:11 +0100, "Tom Melly" <tom### [at] tomandlucouk> wrote:
> a) is this correct? (well, it's not, afaik - the range 1..2 is too limited imho)
> b) if not, what is?

My answer is not real answer but ... there is a macro in rand.inc include file
in standard distribution called VRand_On_Sphere.

ABX

Post a reply to this message

"Tim Nikias" <tim### [at] gmxde> wrote in message
news:3dabfad8@news.povray.org...
> I've come across the same problem some time ago,
> so I implemented a macro which calculated an
> electrostatic-repulsion algorithm. Some animations of
> this macro can be found on my website.
>
> If you want the code, I can see if I have to clean
> the code a little or if I can send it to you right
> away, just give me an email-adress.
>

Probably overkill in this case ("electrostatic repulsion algorithm"? Yoiks!) -
I've got some close approximations working (well, good enough for gov. work).,
but many thanks for the offer.

Post a reply to this message

"ABX" <abx### [at] abxartpl> wrote in message
news:rkunqu4ivtu7928rrf12ti4jo7jn8u86r6@4ax.com...

> My answer is not real answer but ... there is a macro in rand.inc include file
> in standard distribution called VRand_On_Sphere.
>

Ah, many thanks.....

Eep - I thought it might give me a clue, but I can't understand it at all. I
could rewrite some stuff to allow me to use it in this particular instance, but
that won't be as much fun as actually learning something....

Post a reply to this message

I'm not sure if its overkill, depends on what
you're trying to achieve. Still, the macro is very
easy to handle and needs to be run only once,
the data is then saved and can be loaded with
my I/O-Macros (which are available on my website).

But it depends on the amount of objects you're trying
to spread, as always with algorithms pending on amount...

Regards,
Tim

--
Tim Nikias
Homepage: http://www.digitaltwilight.de/no_lights/index.html
Email: Tim### [at] gmxde

>
> Probably overkill in this case ("electrostatic repulsion algorithm"?
Yoiks!) -
> I've got some close approximations working (well, good enough for gov.
work).,
> but many thanks for the offer.
>

Post a reply to this message

"Tim Nikias" <tim### [at] gmxde> wrote in message
news:3dac02a1$1@news.povray.org...
> I'm not sure if its overkill, depends on what
> you're trying to achieve. Still, the macro is very

Branch coral (well, distributing the coral) - I've posted an image to
binaries.images

Post a reply to this message

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

That randomly distributed point macro ABX brought up, VRand_On_Sphere() is
of course 'random', and looking at that now I don't know how to go about
derandomizing it. Trying to here and I get nonuniform distribution and
nothing better.

Post a reply to this message

"Tom Melly" <tom### [at] tomandlucouk> wrote in message
news:3dabf5ef$1@news.povray.org...

Hmm, this seems to work for a hemisphere (which is all I need - although I'm
going to try and figure out how to make it work with any specified max angle).

// okay where MZRot = 90
#local ZRot = pow(rand(Rand1),0.5) * MZRot;
#local YRot = rand(Rand1) * MYRot;

Post a reply to this message

"Tom Melly" <tom### [at] tomandlucouk> wrote in message
news:3dac1e3c@news.povray.org...
>
> Hmm, this seems to work for a hemisphere (which is all I need - although I'm
> going to try and figure out how to make it work with any specified max angle).
>
> // okay where MZRot = 90
> #local ZRot = pow(rand(Rand1),0.5) * MZRot;
> #local YRot = rand(Rand1) * MYRot;
>


and this (rather kludgy) approach seems to work for a specified MZRot:

    #local ZRot = pow(rand(Rand1),0.5) * 90;
    #local YRot = MYRot*rand(Rand1);
    #if(rand(Rand1)<0.5)
      #local ZRot = 180 - ZRot;
    #end
    #if(ZRot <= MZRot)
            .... position coral
            ..... increment counter
    #end

Post a reply to this message

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

Christopher James Huff wrote:

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

Yep, that's essentially what I *tried* to say ;) Should've checked my 
message more carefully before sending, the last sentence ("...so that...") 
doesn't make much sense now. It should read something like "so that the 
distances between every point and its nearest neighbout are roughly equal", 
which is, of course, exactly what you said.

But this is getting a bit off-topic, as it's clear by now that what Tom 
wants is not an even distribution by the definition above, but a *flat* 
random distribution on a sphere :)

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? I
> assume it's something like:
> ZRotFac = 1 + pow(abs((ZRot/90)-1),2);
> ZRot = ZRot * ZRotFac
> 
> But,
> 

I'd say you need for RotZ a random distribution with probability 
proportional to sin(RotZ) (i.e. values close to 90 are more likely than 
values close to 0 or 180). So the problem is to get such a distribution 
from the uniform one that rand(x) gives (or should give). I'm not sure if 
asin(rand(x)) would do the trick (you'd have to make it fit into 0-180, I 
guess not.
You could try picking two random numbers, x and y, if y < sin(x) then RotZ = 
180*x

Post a reply to this message

Jellby wrote:

> You could try picking two random numbers, x and y, if y < sin(x) then RotZ
> = 180*x

Sorry, it's partly wrong and incomplete.

1. pick x and y
2. if y < sin(180*x) then RotZ = 180*x
3. else, go to 1

-- 
Ignacio Fernández Galván
Linux User #289967 (counter.li.org)
PGP Pub Key ID: 0x01A95F99 (pgp.escomplinux.org)

Post a reply to this message

On Fri, 18 Oct 2002 19:57:36 +0100, "Tom & Lu Melly"
<all### [at] tomandlucouk> wrote:

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

Pardon me for jumping in late.  If you just want to scatter
stuff on a sphere randomly without clumping at the poles,
it can be done.  I'll post source on povray.text.scene-files.
The subject should be "random points on a sphere"

Post a reply to this message