Zeger Knaepen wrote:
> 
> > Because it uses a fixed table for the sample directions.  If you know a
> > way for generating an arbitrary number of sample directions on the fly
> > with random yet uniform distribution (and cos theta density distribution)
> > you are welcome to share it... ;-)
> 
> Why is a fixed table necessary?

Have you read what i wrote?

I don't know a method to generate such a distribution in high quality that
would be fast enough to be run before every render - if you do feel free
to implement it. 

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 07 Dec. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

Christoph Hormann wrote:
> Because it uses a fixed table for the sample directions.  If you know a
> way for generating an arbitrary number of sample directions on the fly
> with random yet uniform distribution (and cos theta density distribution)
> you are welcome to share it... ;-)

Actually, that's easy, if I understand the question correctly: let (x, y) be
a random point in the unit circle (x^2 + y^2 <= 1), and let z = sqrt(1 -
x^2 - y^2).

Anders

--
light_source{6#local D=#macro B(E)#macro A(D)#declare E=(E-#declare
C=mod(E D);C)/D;C#end#while(E)#if(A(8)=7)#declare D=D+2.8;#else#if(
C>2)}torus{1..2clipped_by{box{-2y}}rotate<1 0C>*90translate<D+1A(2)
*2+1#else}cylinder{0(C-v=1).2translate<D+C*A(2)A(4)#end-2 13>finish
{specular 1}pigment{rgb x}#end#end#end-8;1B(445000298)B(519053970)B
(483402386)B(1445571258)B(77778740)B(541684549)B(42677491)B(70)}

Post a reply to this message

"Christoph Hormann" <chr### [at] gmxde> schreef in bericht
news:3E0F156E.AB321B83@gmx.de...
> Zeger Knaepen wrote:
> >
> > > Because it uses a fixed table for the sample directions.  If you know
a
> > > way for generating an arbitrary number of sample directions on the fly
> > > with random yet uniform distribution (and cos theta density
distribution)
> > > you are welcome to share it... ;-)
> >
> > Why is a fixed table necessary?
>
> Have you read what i wrote?
Yep, and although I did misunderstand your question :) , my question
remains: if it's possible to calculate 1600 fixed sample directions, it
should also be possible (using the same or a similar algorythm) to calculate
an arbitrary amount of fixed sample directions before the actual raytracing
starts.  That way, you don't have to calculate the sample directions on the
fly, and there wouldn't be an upperlimit of 1600 samples.  Or am I talking
nonsense here?

> I don't know a method to generate such a distribution in high quality that
> would be fast enough to be run before every render - if you do feel free
> to implement it.
I don't know what a "cos theta density distribution" is, but aren't just
random (and not (perfectly) uniform distributed) rays good enough?

Oh, and an other question: reading the POV-Ray manual gave me the impression
that the re-use of samples is based on the distance of the previous sample.
As far as I can remember, there's nothing about the surface-normal in the
manual.  But IMHO, the surface normal is more (or equaly) important to
decide if samples could be re-used.  Am I wrong?  Or is this maybe already
implemented?
Just a thought... :)  Don't shoot me if I'm wrong :)

cu!
--
ZK AKA SaD
http://www.povplace.be.tf
"Smoke me a kipper, I'll be back for breakfast."

Post a reply to this message

Zeger Knaepen wrote:
> 
> > > Why is a fixed table necessary?
> >
> > Have you read what i wrote?
> Yep, and although I did misunderstand your question :) , my question
> remains: if it's possible to calculate 1600 fixed sample directions, it
> should also be possible (using the same or a similar algorythm) to calculate
> an arbitrary amount of fixed sample directions before the actual raytracing
> starts.  That way, you don't have to calculate the sample directions on the
> fly, and there wouldn't be an upperlimit of 1600 samples.  Or am I talking
> nonsense here?

No, but generating a good distribution is a slow and difficult thing.  So
calculating them before every render is no good idea.

Any practical solution will have to supply a precalculated table or a tool
for calculating it (so the user is more flexible with the maximum count).

> > I don't know a method to generate such a distribution in high quality that
> > would be fast enough to be run before every render - if you do feel free
> > to implement it.
> I don't know what a "cos theta density distribution" is, but aren't just
> random (and not (perfectly) uniform distributed) rays good enough?

"cos theta density distribution" means the density of the samples is not
constant but proportional to the cosine of the angle to the normal vector.

Whether random rays are 'good enough' is a matter of personal taste of
course but i don't think anyone would use a completely random sampling if
available.

> Oh, and an other question: reading the POV-Ray manual gave me the impression
> that the re-use of samples is based on the distance of the previous sample.
> As far as I can remember, there's nothing about the surface-normal in the
> manual.  But IMHO, the surface normal is more (or equaly) important to
> decide if samples could be re-used.  Am I wrong?  Or is this maybe already
> implemented?

I'm not sure what you mean but the distribution of the samples depends on
the scene geometry (or the surface normal if you want so).  There is a
switch in the POV source you can make the sample positions visible with so
you can see this.  If this is not what you mean please clarify what you
mean by 'basing the reuse of samples on something'.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 07 Dec. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

"Christoph Hormann" <chr### [at] gmxde> schreef in bericht
news:3E0F289C.4100D6CD@gmx.de...
> > Yep, and although I did misunderstand your question :) , my question
> > remains: if it's possible to calculate 1600 fixed sample directions, it
> > should also be possible (using the same or a similar algorythm) to
calculate
> > an arbitrary amount of fixed sample directions before the actual
raytracing
> > starts.  That way, you don't have to calculate the sample directions on
the
> > fly, and there wouldn't be an upperlimit of 1600 samples.  Or am I
talking
> > nonsense here?
> No, but generating a good distribution is a slow and difficult thing.  So
> calculating them before every render is no good idea.

hmm, ic..

> Any practical solution will have to supply a precalculated table or a tool
> for calculating it (so the user is more flexible with the maximum count).
>
> > > I don't know a method to generate such a distribution in high quality
that
> > > would be fast enough to be run before every render - if you do feel
free
> > > to implement it.
> > I don't know what a "cos theta density distribution" is, but aren't just
> > random (and not (perfectly) uniform distributed) rays good enough?
> "cos theta density distribution" means the density of the samples is not
> constant but proportional to the cosine of the angle to the normal vector.

You mean there will be less samples directed more or less perpendicular to
the surface than those directed more or less parellel to the surface?  Why
is this needed?

> Whether random rays are 'good enough' is a matter of personal taste of
> course but i don't think anyone would use a completely random sampling if
> available.

I know I would, if it was the only way to have more than 1600 samples...
How about this: for the first 1600 samples, use the precalculated table, but
for the next n samples, use a random direction. :)

> > Oh, and an other question: reading the POV-Ray manual gave me the
impression
> > that the re-use of samples is based on the distance of the previous
sample.
> > As far as I can remember, there's nothing about the surface-normal in
the
> > manual.  But IMHO, the surface normal is more (or equaly) important to
> > decide if samples could be re-used.  Am I wrong?  Or is this maybe
already
> > implemented?
> I'm not sure what you mean but the distribution of the samples depends on
> the scene geometry (or the surface normal if you want so).  There is a
> switch in the POV source you can make the sample positions visible with so
> you can see this.  If this is not what you mean please clarify what you
> mean by 'basing the reuse of samples on something'.
I think I'll just assume that the way POV-Ray samples is as good as can be
:)  I'm afraid my English isn't good enough to explain better what I was
trying to say :-/ but I think, if I understand you correctly, things are the
way I think they should be :)

cu!
--
ZK AKA SaD
http://www.povplace.be.tf
"I'm not expendable, I'm not stupid and I'm not going."

Post a reply to this message

Christoph Hormann <chr### [at] gmxde> wrote in
news:3E0F289C.4100D6CD@gmx.de 

> Any practical solution will have to supply a precalculated table or a
> tool for calculating it (so the user is more flexible with the maximum
> count). 

Why didn't You answare my question - so why not pre-calculate i.e. 20,000 
values instead of just 1,600 ?

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

> Actually, that's easy, if I understand the question correctly: let (x, y)
be
> a random point in the unit circle (x^2 + y^2 <= 1), and let z = sqrt(1 -
> x^2 - y^2).


That doesn't have a uniform distribution.

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

Post a reply to this message

http://mathworld.wolfram.com/SpherePointPicking.html.

Post a reply to this message

I wrote:
> > Actually, that's easy, if I understand the question correctly: let (x,
y)
> be
> > a random point in the unit circle (x^2 + y^2 <= 1), and let z = sqrt(1 -
> > x^2 - y^2).

Slime wrote:
> That doesn't have a uniform distribution.

Right. It has cos theta distribution, like Christoph asked for.

Anders

--
light_source{6#local D=#macro B(E)#macro A(D)#declare E=(E-#declare
C=mod(E D);C)/D;C#end#while(E)#if(A(8)=7)#declare D=D+2.8;#else#if(
C>2)}torus{1..2clipped_by{box{-2y}}rotate<1 0C>*90translate<D+1A(2)
*2+1#else}cylinder{0(C-v=1).2translate<D+C*A(2)A(4)#end-2 13>finish
{specular 1}pigment{rgb x}#end#end#end-8;1B(445000298)B(519053970)B
(483402386)B(1445571258)B(77778740)B(541684549)B(42677491)B(70)}

Post a reply to this message

"Rafal 'Raf256' Maj" <raf### [at] raf256com> wrote...
> Christoph Hormann <chr### [at] gmxde> wrote in
> news:3E0EEC6A.7B42D7F9@gmx.de
>
> >> Why is there an upper-limit of 1600 for radiosity-samples?
> > Because it uses a fixed table for the sample directions.
>
> Algorithm that was used to generate 1600 elements fixed array - can it be
> used to generate i.e. 20,000 fixed elements array ?

The 1600 pre-calculated elements were NOT randomly generated using a
pseudo-random sequence and a probability distribution function.  Instead,
there were carefully calculated by a special custom program.  As far as I
know, we don't have the source code for that program.

To understand why, take a look at the recent post by Mael titled "Sampling
in pov3.1" in povray.unofficial.patches.  Also check out his website here:
http://195.221.122.126/samples/samples.html

From these images you can easily see that the radiosity samples were
carefully chosen to be very evenly spaced.  This is designed to reduce
splotchiness caused by uneven sampling.

-Nathan

Post a reply to this message