> Ok, that makes me wonder, because:
>
> 1. The 2 methods above produce 100% identical images. It was a scene of
> one light emitting sphere, ground and 3 diffusing spheres of different
> colors. (I did use the cosine ratio relative to the angle of light
> falling on surface.) I can post the images if needed. The only
> difference is that the second method is faster - with a great margin.
>
> 2. If the distribution is not identical by the 2 methods, why are the
> images still 100% identical?

Actually yes, they are both the same, and wrong ;-)  I hadn't checked your 
y=sqrt(rand()) method, just assumed it was correct.

A correct way is:

y = rand(0...1);
phi = rand(0...2pi)
x = sqrt(1-y*y) * cos(phi)
z = sqrt(1-y*y) * sin(phi)

This will give a more even distribution, if you visualise the results you'll 
see that your earlier attempts don't give many points around the equator.

Post a reply to this message

> Actually yes, they are both the same, and wrong ;-)  I hadn't checked
> your y=sqrt(rand()) method, just assumed it was correct.
> 
> A correct way is:
> 
> y = rand(0...1);
> phi = rand(0...2pi)
> x = sqrt(1-y*y) * cos(phi)
> z = sqrt(1-y*y) * sin(phi)
> 
> This will give a more even distribution, if you visualise the results
> you'll see that your earlier attempts don't give many points around the
> equator.

I made finally a test program to see the distribution by looking down
the sphere. It seems that the above method and the first method in this
thread (x= sin(theta)*cos(phi)...) BOTH should NOT have sqrt to produce
even distribution on surface. It also seems that if the sqrt is
included, all 3 methods produce identical distribution which is weighted
to pole -> ie. less points on the equator. Or if you look along y axis,
they have uniform distribution projected on XZ plane.

Post a reply to this message

>> Another way is to generate a random vector:
>>
>> #local vResult=vrotate(x,<rand(Seed),rand(Seed),rand(Seed)>*360);
> 
> vResult is not uniformly distributed over the sphere with this approach 
> though...
> 

rand.inc has macros that return random vectors uniformly distributed 
over a sphere's volume or surface.

Post a reply to this message

Severi Salminen wrote:
> scott wrote:
>>> Another way is to generate a random vector:
>>>
>>> #local vResult=vrotate(x,<rand(Seed),rand(Seed),rand(Seed)>*360);
>> vResult is not uniformly distributed over the sphere with this approach
>> though...
> 
> I use this:
> 
> y = sqrt(rand(0..1))
> theta = acos(y)
> phi = 2*PI*rand(0..1)
> 
> x = sin(theta)*cos(phi)
> z = sin(theta)*sin(phi)
> 
> What I don't get is the sqrt(rand()). Why sqrt? Why not just rnd()? Does
> the sqrt give us the cosine distribution and should remove the need to
> later scale by taking cosine of the angle between normal and the light ray?

Actually, a plain rand() should work fine.  I did the calculus.

y = rand(0..1)
s = sqrt(1-y*y)
phi = 2*PI*rand(0..1)
x = s*cos(phi)
z = s*sin(phi)

Regards,
John

Post a reply to this message

scott wrote:

>> What I don't get is the sqrt(rand()). Why sqrt? Why not just rnd()? Does
>> the sqrt give us the cosine distribution and should remove the need to
>> later scale by taking cosine of the angle between normal and the light
>> ray?
> 
> No, you are simply choosing a fixed Y position, which then defines a
> ring around the sphere of possible points.  Then phi is used to choose a
> point at random on this ring which gives you the final point.

I made a few more tests. And it really seems to be that if you use
cosine weighted distribution (with sqrt around y -> less rays at
equator, more at pole) you don't need to calculate cosine at all during
tracing! Benefits:

1. No need to do cosine calculation. This might be good/bad depending on
how you create the cosine weighted rays and how you would've calculated
the cosine. At least on my program it is faster to do one sqrt() than to
calculate the cosine of two vectors with dot product of the two.

A much bigger benefit:

2. It seems that you get less variance with this weighted method because
 rays coming near the normal give more information than rays coming from
equator. I guess this is called "importance sampling".

I'm testing this now and the new method gives identical results after
about 250 passes compared to about 360 passes of the old method. Judged
by my eye. And in addition each pass takes 10% less time than the old one!

So a BIG improvement!! That is if I'm not missing something important here.

I have to find a way to analyze the actual variance (noisiness) of the
image so that I don't have to trust my eyes. Any ideas?

Post a reply to this message