The following macro gives an uniform distribution within the sphere{0,1}
and is slightly faster (by 9%) than VRand_In_Sphere() from rand.inc:

#macro VRand_In_Sphere(Stream)
  #local Y = 2*rand(Stream)-1;
  vrotate ( (<sqrt(1-Y*Y),Y,0>*pow(rand(Stream),1/3)), 360*rand(Stream)*y )
#end


And this macro gives an uniform distribution on the surface of the
sphere{0,1}. It's slightly faster than VRand_On_Sphere() from rand.inc:

#macro VRand_On_Sphere(Stream)
  #local Y = 2*rand(Stream)-1;
  vrotate ( <sqrt(1-Y*Y), Y, 0>, 360*rand(Stream)*y )
#end


I suggest to replace the original rand.inc macros by these macros.

   Sputnik

Post a reply to this message

> <sqrt(1-Y*Y),Y,0>

I think that will cause points to be more dense towards the top and bottom
of the sphere, won't it?

It might be possible to correct it by running Y through some function like
acos() or something, but that would have to be researched.

 - Slime
 [ http://www.slimeland.com/ ]

Post a reply to this message

Can you mathematically prove that the distribution is even?

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

In article <3fa9f0a2$1@news.povray.org>,
 "Frank 'Sputnik' Rothfuß" <fr### [at] computermuseumfh-kielde> wrote:

> I suggest to replace the original rand.inc macros by these macros.

Hmm, I haven't had time to go over the mathematics, but these look like 
they do give even results...

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

Well, after understanding the message and going into its math a bit 
more, I came to following conclusions.

I think we can agree that if Frank's VRand_On_Sphere is uniform on the 
sphere then VRand_In_Sphere is uniform within the sphere.

So I considered VRand_On_Sphere which is a bit easier.
First remark I made is that the repartition is not obviously uniform.  :-)

What seem to happen here is that we have a combination of two 
non-uniform transformations that may lead to a uniform repartition.

<sqrt(1-Y*Y), Y, 0> is non uniform in terms of length of the circle, 
there will be more points in the middle of the circle and less at the 
top and bottom, but then the rotation is not uniform either as it will 
spread the points of the top and bottom on smaller surfaces.

The remaining question is : does the one exactly counter the other ?

I haven't answered this one yet, and I would really like to avoid doing 
it with my rusty math, isn't any math student around willing to do it ?? 
There's just a few arcos integrals and stuff like that implied I think.  :-)

JC

Frank 'Sputnik' Rothfuß wrote:
> The following macro gives an uniform distribution within the sphere{0,1}
> and is slightly faster (by 9%) than VRand_In_Sphere() from rand.inc:
> 
> #macro VRand_In_Sphere(Stream)
>   #local Y = 2*rand(Stream)-1;
>   vrotate ( (<sqrt(1-Y*Y),Y,0>*pow(rand(Stream),1/3)), 360*rand(Stream)*y )
> #end
> 
> 
> And this macro gives an uniform distribution on the surface of the
> sphere{0,1}. It's slightly faster than VRand_On_Sphere() from rand.inc:
> 
> #macro VRand_On_Sphere(Stream)
>   #local Y = 2*rand(Stream)-1;
>   vrotate ( <sqrt(1-Y*Y), Y, 0>, 360*rand(Stream)*y )
> #end
> 
> 
> I suggest to replace the original rand.inc macros by these macros.
> 
>    Sputnik
> 
>

Post a reply to this message

> <sqrt(1-Y*Y), Y, 0> is non uniform in terms of length of the circle,
> there will be more points in the middle of the circle and less at the
> top and bottom, but then the rotation is not uniform either as it will
> spread the points of the top and bottom on smaller surfaces.
>
> The remaining question is : does the one exactly counter the other ?

Good point. It may very well do so. The <sqrt(1-Y*Y), Y, 0> distribution is
related to the cosine of the angle from the center of the circle to the
point <sqrt(1-Y*Y), Y, 0>. Also, the circumference of the circle which that
point is then randomly placed on is proportional to the cosine of the same
angle. Therefore, it's possible that this VRand_On_Sphere() function does in
fact work properly.

It needs to be worked out formally though.

 - Slime
 [ http://www.slimeland.com/ ]

Post a reply to this message

JC (Exether) wrote:

> I haven't answered this one yet, and I would really like to avoid doing
> it with my rusty math, isn't any math student around willing to do it ??
> There's just a few arcos integrals and stuff like that implied I think. 
> :-)
> 
Well... I just posted an article until it popped up in my mind that 
it was complete nonsense, so I canceled it again (hope that helps...)
Furthermore (as non-native speaker) I mixed up longitude and latitude 
again -- @#$%!!!

I had to take pencil and paper and have a closer look: 

>> And this macro gives an uniform distribution on the surface of the
>> sphere{0,1}. It's slightly faster than VRand_On_Sphere() from rand.inc:
>> 
>> #macro VRand_On_Sphere(Stream)
>>   #local Y = 2*rand(Stream)-1;
>>   vrotate ( <sqrt(1-Y*Y), Y, 0>, 360*rand(Stream)*y )
>> #end
>
Okay, so the area size on a sphere between latitudes theta1 and theta2 
is (where theta is not really the latitude but measured downwards from 
the pole): 
  integral theta1..theta2 over 2*pi*sin(theta) d(theta)
which is
  area = 2*pi*(cos(theta1)-cos(theta2))

The probability for the vector to be inside that area is: 
  P(v in area) = P(cos(theta2)<= y < cos(theta1))
where y=2*rand(Stream)-1, i.e. uniformly distributed, so 
  P = ( cos(theta1)-cos(theta2) )/2

Now, if the probability is proportional to the area, the distribution 
is uniform. Looking at the formulas, this is evident: 
  P/area = 1/(4*pi)
...which is just what we expect and independent of theta1 and theta2. 

So I think that it really works. 

Cheers,
Wolfgang

Post a reply to this message

"JC (Exether)" <no### [at] spamfr> wrote:
> I think we can agree that if Frank's VRand_On_Sphere is uniform on the 
> sphere then VRand_In_Sphere is uniform within the sphere.

  Well, I think this is not automatic, but needs proof. :)

  (Btw, has anyone proven mathematically that the current official
macros produce even distributions?)

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

>   (Btw, has anyone proven mathematically that the current official
> macros produce even distributions?)

I am convinced that they do.

Honestly, I'm not sure of the proper mathematical procedures to use when
evaluating a distribution curve. Nonetheless, I understand the logic behind
what causes an uneven distribution and how to go about correcting it; I have
a very good intuition about this sort of thing (IMO at least ;) ) and during
the POV-Ray 3.5 beta I took a good look at the two functions out of
curiosity. I determined, simply by reading the code, that the
VRand_In_Sphere function provided an uneven distribution, because it wasn't
using the pow(..., 1/3) trick to pull things away from the center. I
verified my suspicions, fixed the problem and submitted what is now the
current VRand_In_Sphere function.

Anyway, I've thought long and hard about both functions, and I am absolutely
certain that both of them provide even distributions.

I have been known to be wrong... =)

 - Slime
 [ http://www.slimeland.com/ ]

Post a reply to this message

Warp wrote:
> "JC (Exether)" <no### [at] spamfr> wrote:
>> I think we can agree that if Frank's VRand_On_Sphere is uniform on the
>> sphere then VRand_In_Sphere is uniform within the sphere.
> 
>   Well, I think this is not automatic, but needs proof. :)
> 
I think my posting from yesterday proofs it. 
The vector is rotated by a random amount around the Y axis, so it 
is sufficient to prove that the probability for the vector being 
in a certain latitude range is equal to the area covered by it 
(divided by 4pi, of course). Now read on in my previous posting. 

Wolfgang

Post a reply to this message

Frank 'Sputnik' Rothfuß wrote:
> I suggest to replace the original rand.inc macros by these macros.

Even if the distribution of these functions are indeed even, it should
still be considered that some scenes made using the current macros may
be designed to depend on their exact output, not just the distribution.
(Just like some scenes were made to depend on the old noise_generator
before it was changed in POV-Ray 3.5.) This means that if new macros
with different output are introduced, backward compatible alternative
macros must be provided as well. This however, doesn't necessarily
prevent some users from being confused when their scenes suddenly look
different, if they're not aware of the new macros that have replaced the
old ones.

Now the question is: Is the 9% speed increase worth the hassle with the
backwards compatibility issue? I'm not for or against, I just want to
make sure that the issue is being considered.

Rune
--
3D images and anims, include files, tutorials and more:
rune|vision:  http://runevision.com **updated Sep 28**
POV-Ray Ring: http://webring.povray.co.uk

Post a reply to this message

In article <3fac3188@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   (Btw, has anyone proven mathematically that the current official
> macros produce even distributions?)

Well, I've done empirical tests that seem to show that they do. And come 
up with another interesting fact: points on a sphere are uniformly 
distributed on each axis. Makes sense once you realize why (The 
boundaries of each slice subtend a greater angle as you near the edge of 
the sphere, where the radius is smaller. Any two slices through a sphere 
of the same thickness have the same surface area.), but a bit surprising 
to realize.

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

Rune <run### [at] runevisioncom> wrote:
> Now the question is: Is the 9% speed increase worth the hassle with the
> backwards compatibility issue? I'm not for or against, I just want to
> make sure that the issue is being considered.

  Probably not worth.

  To get a speed boost you can simply copy the macro from the include
file to your scene file. This should noticeably increase its speed due
to how POV-Ray parses macros in include files.

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

In article <3fad31ab@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

> Rune <run### [at] runevisioncom> wrote:
> > Now the question is: Is the 9% speed increase worth the hassle with the
> > backwards compatibility issue? I'm not for or against, I just want to
> > make sure that the issue is being considered.
> 
>   Probably not worth.
> 
>   To get a speed boost you can simply copy the macro from the include
> file to your scene file. This should noticeably increase its speed due
> to how POV-Ray parses macros in include files.

A speed boost, but for a different reason. This new version is indeed 
faster (by 12% by my measurements...call it 10%). It's also shorter and 
easier to understand. I doubt there would be very many scenes that would 
be adversely affected. The macro versions defined could be made 
conditional on the POV-Ray #version, or just left alone with slightly 
modified names. It's a small improvement, but I think it would be worth 
it...assuming the macros can be proven to work right. (They seem to, 
from my measurements, but I haven't proven it.)

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

> Now the question is: Is the 9% speed increase worth the hassle with the
> backwards compatibility issue? I'm not for or against, I just want to
> make sure that the issue is being considered.

Is it possible to use SDL to determine the current #version, and then define
a different macro based on that? Then the better versions could be used for
scene files marked for version 3.5.1 (or whatever), and the older versions
used for older scene files.

 - Slime
 [ http://www.slimeland.com/ ]

Post a reply to this message

Christopher James Huff wrote:

> it...assuming the macros can be proven to work right. (They seem to,
> from my measurements, but I haven't proven it.)
> 
What exactly do you understand by a "proof"?

Wolfgang

Post a reply to this message

Wolfgang Wieser wrote:
> What exactly do you understand by a "proof"?

Alchohol content of a beverage, percentage divided by half.

Post a reply to this message

Wolfgang Wieser <wwi### [at] gmxde> wrote:
> What exactly do you understand by a "proof"?

  Mathematical proof. Should be unambiguous and checkable by anyone.

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

On Sat, 08 Nov 2003 18:34:08 -0500, Tim Cook <z99### [at] bellsouthnet> wrote:

>Alchohol content of a beverage, percentage divided by half.

I beg to differ, Quote …
Only the English could invent 'proof' in 1762, which was the technical standard
by which strength was measured until 1st January, l980.   If  gunpowder and
alcohol were mixed and  the spirit was weaker than proof strength (57% ABV),
there was just a damp fizzle. However, when whisky and gunpowder were mixed  and
there was enough alcohol in the mixture to cause ignition, then the gunpowder
flashed, providing the 'proof' of  stronger alcohol.  

To compare: Gay Lussac's ABV to UK and US Proof:

100% (Pure alcohol)  =  175 UK Proof  = 200 US proof 
50% =  87.5 UK Proof = 100 US proof
46% =   80.5 UK Proof = 92 US prof

For UK proof  multiply ABV by 1.75, for US double it

Regards
        Stephen

Post a reply to this message

Stephen McAvoy wrote:
> On Sat, 08 Nov 2003 18:34:08 -0500, Tim Cook <z99### [at] bellsouthnet> wrote:
>>Alchohol content of a beverage, percentage divided by half.
> To compare: Gay Lussac's ABV to UK and US Proof:
> 100% (Pure alcohol)  =  175 UK Proof  = 200 US proof 
> 50% =  87.5 UK Proof = 100 US proof
> 46% =   80.5 UK Proof = 92 US prof

There, see?  I was right by way of accident in wording my formula;
dividing something BY half, not IN half, is the same as multiplying
by two...haha!  *sweatdrop*  *hides*

Post a reply to this message

On Sun, 09 Nov 2003 05:10:37 -0500, Tim Cook <z99### [at] bellsouthnet> wrote:

> I was right by way of accident in wording my formula;

By accident? No, I don't believe that.

Regards
        Stephen

Post a reply to this message

Warp wrote:

> Wolfgang Wieser <wwi### [at] gmxde> wrote:
>> What exactly do you understand by a "proof"?
> 
>   Mathematical proof. Should be unambiguous and checkable by anyone.
> 
Then please check my proof in the other posting(s). 
It should be easy to follow. For convenience, I copy-and-paste 
it here again: 

A: VRand_On_Sphere(): surface vectors. 

The vector is rotated by a random amount around the Y axis, so it 
is sufficient to prove that the probability for the vector being 
in a certain latitude range is equal to the area covered by it 
(divided by 4pi, of course). 

The area size on a sphere between latitudes theta1 and theta2 
is (where theta is not really the latitude but measured downwards from 
the pole): 
  integral theta1..theta2 over 2*pi*sin(theta) d(theta)
which is
  area = 2*pi*(cos(theta1)-cos(theta2))

The probability for the vector to be inside that area is: 
  P(v in area) = P(cos(theta2)<= y < cos(theta1))
where y=2*rand(Stream)-1, i.e. uniformly distributed, so 
  P = ( cos(theta1)-cos(theta2) )/2
(because y = r * cos(theta) and r=1 here). 

Now, the probability per area can be calculated as: 
  P/area = 1/(4*pi)
...which is just what we expect and independent of theta1 and theta2. 

- q.e.d. 

So, it works for the sphere surface vectors. 

B: VRand_In_Sphere(), full sphere. 

For the full sphere, there is not much difference, just the 
radius is chosen to be randomly distributed using 
pow(rand(Stream),1/3)). 
I don't believe that this is right until someone (me?) proves 
it to be right - ;)

Wolfgang

Post a reply to this message

Wolfgang Wieser wrote:
> B: VRand_In_Sphere(), full sphere.
> 
> For the full sphere, there is not much difference, just the
> radius is chosen to be randomly distributed using
> pow(rand(Stream),1/3)).
> I don't believe that this is right until someone (me?) proves
> it to be right - ;)
> 
As shown last time, we already have a function for the uniform 
distribution on a sphere surface. For the VRand_In_Sphere() function, 
it is therefore sufficient to prove that the radius calculation 
(i.e. vector length) is correct. 

For that purpose, it must be shown that the probability for the 
vector being of a certain length range is equal to the volume 
enclosed by that radius range (divided by 4*pi/3, of course). 

The sphere volume between radii r1 and r2 (r2>r1) is: 
  V = 4*pi/3 * (r2^3 - r1^3)

The vector length l is calculated as l=a^(1/3) with a=rand(Stream), 
hence l^3 is uniformly distributed in the range 0..1. 

The probability for the vector to end in the volume V (i.e. radius 
range r1..r2) is: 
  P(vector in V) = P(r1 <= l < r2) = P(r1^3 <= l^3 < r2^3) = 
and as l^3=a:
  = P(r1^3 <= a < r2^3) = r2^3 - r1^3

Hence, the quotient (probability per volume) is: 
  P/V = 3/(4*Pi)
...which is what we want. 

- q.e.d. 

So, it works; VRand_In_Sphere() is uniformly distributed in the sphere. 

Any doubts or problems?

Wolfgang

Post a reply to this message

I vote for 'not worth'.
I'm pretty much convinced that the proposed distribution are even, but I 
agree with your arguments. And I would also add that it is better to 
have a clearly even distribution in the include file rather than a 
distribution that is very clever but not so clear, even if it's faster.

JC


Rune wrote:
> Frank 'Sputnik' Rothfuß wrote:
> 
>>I suggest to replace the original rand.inc macros by these macros.
> 
> 
> Even if the distribution of these functions are indeed even, it should
> still be considered that some scenes made using the current macros may
> be designed to depend on their exact output, not just the distribution.
> (Just like some scenes were made to depend on the old noise_generator
> before it was changed in POV-Ray 3.5.) This means that if new macros
> with different output are introduced, backward compatible alternative
> macros must be provided as well. This however, doesn't necessarily
> prevent some users from being confused when their scenes suddenly look
> different, if they're not aware of the new macros that have replaced the
> old ones.
> 
> Now the question is: Is the 9% speed increase worth the hassle with the
> backwards compatibility issue? I'm not for or against, I just want to
> make sure that the issue is being considered.
> 
> Rune
> --
> 3D images and anims, include files, tutorials and more:
> rune|vision:  http://runevision.com **updated Sep 28**
> POV-Ray Ring: http://webring.povray.co.uk
> 
>

Post a reply to this message

"JC (Exether)" <no### [at] spamfr> wrote:
> And I would also add that it is better to 
> have a clearly even distribution in the include file rather than a 
> distribution that is very clever but not so clear, even if it's faster.

  IMHO that's irrelevant.
  The main features should be speed and ease of use. Algorithmic complexity
is irrelevant.

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

Oh boy, what a long thread ...

I've not looked at this thread for a while and I am astonished
about the many responses (and strange sidetracks ...). Next time
when I post such a thing I will provide a proof together with it,
but here it seems unneccessary now as Wolfgang did it (thanks for
that).

Because the usage of such a macro should not depend on its inner
workings, I think it is bad (or at least questionable) programming
style to rely on the specific algorithm used for the implementation.
(Remember: the macro is supposed to deliver *random* points, so
even a truly random hardware generator that never repeats the same
(long) sequence should be accepted!)
If this dependence is required, the macro should be *copied* to the
scene: this will prevent these special scenes from breaking while
leaving room for improvements for the majority of the other scenes.
(BTW: calling a copied macro is *much* faster than calling an
included macro, when it is used very often.)
Refraining from such improvements sounds to me a little bit like
"don't improve the accuracy of POV-Ray's geometric calculations,
my scene depends on the rounding errors". (O.K., don't take this
argument toooo seriously: I wrote "to me" and "a little bit" :-)

So I now suggest to use the new macros in rand.inc, but leave
the old macros as comment (or renamed to ..._Old).
Or: leave the old macros and include my macros with the suffix
"_New" or as comment ...

   Sputnik

Post a reply to this message

"Frank 'Sputnik' Rothfuß" <fr### [at] computermuseumfh-kielde> wrote in message
news:3fb30aa5$1@news.povray.org...
> Oh boy, what a long thread ...

> Because the usage of such a macro should not depend on its inner
> workings, I think it is bad (or at least questionable) programming
> style to rely on the specific algorithm used for the implementation.
> (Remember: the macro is supposed to deliver *random* points, so
> even a truly random hardware generator that never repeats the same
> (long) sequence should be accepted!)

<snip>

I think you're missing the point - when using rand in a scene I will often throw
various seeds at it until I get a distribution I like. This distrib will be
random - I'm not aiming for a particular numeric sequence - but in the interests
of a nice image some random sequences will produce better results.

Take a look at:

http://www.tomandlu.co.uk/webres/raytracing/gallery/pics/tmsummer.jpg
and
http://www.tomandlu.co.uk/webres/raytracing/gallery/pics/tmwinter.jpg

the branch distrib is undeniably random, but a different sequence will not
produce the same aesthetic effect. Now in this case I'm using plain rand + my
own algorithms, but if the supplied macros are to be taken seriously, then they
have to produce consistent results. Bug fixing is one thing, but (fairly)
arbitary changes every time a speed-increase is found is another. Much better
IMHO to provide improved macros with different names (or some sort of version
directive as suggested by others).

Post a reply to this message

O.K., now I see this point.

So my macros are good if speed is important, but
"backward compatibility" isn't (if the particular
sequence doesn't matter; and in new scenes);
otherwise the current macros will be neccessary.
Copying is better than including (in the case of
these macros): a copied macro is faster; the scene
is protected from changes in the include file.

   Sputnik

Post a reply to this message

#macro EvenSpherePoint(pos, rad, sd)
    #local irad = sqrt(min(rand(sd),0);
    #local long = rand(sd)*2*pi;
    #local hemi = select(rand(sd)-0.5, -1, 1)
    #local azim = pow(rand(sd), x)*pi*0.5;
    #local dir = <cos(azim)*cos(long), hemi*sin(azim), cos(azim)*sin(long)>;
    #local pnt = pos+dir*irad*rad;
    pnt
#end

What should x be in order to get a truly even distribution (or at least
something close)?

I set up an Excel spreadsheet comparing cos(x*2/pi) to 1-(x*x)^n
for -1<=x<=1 in steps of 0.01 and 0.002.  I calculated the sum of the
differences between the functions, essentially looking of a value of n where
the integrals of these functions were identical.  Excel came up with
0.875969064, or 1/(pi-2).  x in the phi function is double that.

"Wolfgang Wieser" <wwi### [at] gmxde> wrote in message
news:3fae530a@news.povray.org...
> Wolfgang Wieser wrote:
> > B: VRand_In_Sphere(), full sphere.
> >
> > For the full sphere, there is not much difference, just the
> > radius is chosen to be randomly distributed using
> > pow(rand(Stream),1/3)).
> > I don't believe that this is right until someone (me?) proves
> > it to be right - ;)
> >
> As shown last time, we already have a function for the uniform
> distribution on a sphere surface. For the VRand_In_Sphere() function,
> it is therefore sufficient to prove that the radius calculation
> (i.e. vector length) is correct.
>
> For that purpose, it must be shown that the probability for the
> vector being of a certain length range is equal to the volume
> enclosed by that radius range (divided by 4*pi/3, of course).
>
> The sphere volume between radii r1 and r2 (r2>r1) is:
>   V = 4*pi/3 * (r2^3 - r1^3)
>
> The vector length l is calculated as l=a^(1/3) with a=rand(Stream),
> hence l^3 is uniformly distributed in the range 0..1.
>
> The probability for the vector to end in the volume V (i.e. radius
> range r1..r2) is:
>   P(vector in V) = P(r1 <= l < r2) = P(r1^3 <= l^3 < r2^3) =
> and as l^3=a:
>   = P(r1^3 <= a < r2^3) = r2^3 - r1^3
>
> Hence, the quotient (probability per volume) is:
>   P/V = 3/(4*Pi)
> ...which is what we want.
>
> - q.e.d.
>
> So, it works; VRand_In_Sphere() is uniformly distributed in the sphere.
>
> Any doubts or problems?
>
> Wolfgang
>

Post a reply to this message

What are you trying to do? Your messages don't seem to have much to do 
with the ones they reply to. And what advantages do your versions have? 
We already have two simpler versions that are tested and pretty well 
proven to give the correct distribution.

Plus I see several errors in your code, even after syntax is corrected 
enough for the macros to parse...for example, "min(rand(sd),0)" is 
always 0. Using max() doesn't make any more sense...it would have no 
effect. "pow(rand(sd), x)" is meaningless...raising a random number to a 
power of < 1, 0, 0>? Fixing the parentheses and semicolons, removing the 
min(), and substituting 2 for x gave something that didn't even come 
close to an even spherical distribution, with either of your macros.

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