Apache wrote:
> 
> The method is far from perfect, but here is the c code I wrote. I have been
> thinking of a better way, because there there are some faint plateaus in the
> distribution and we don't want that. I guess some smart jittering will get
> rid of the plateaus. The algorithm is VERY SLOW, so I'm afraid that coding
> it in pov SDL is completely useless!
> 
> (Code attached to this post. file extension is .cpp, but the code itself is
> ANSI C.)

You know you should not post binary attachments in a non binary group...

Apart from that - it looks like a regular distribution.  No matter how
uniform it is this is usually a bad idea.  Most of the computations seems
to be required for sorting the samples - this can be removed when you
generate the precise number of samples you need.

Christoph

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

Post a reply to this message

Apache wrote:
> 
> The method is far from perfect, but here is the c code I wrote. I have been
> thinking of a better way, because there there are some faint plateaus in the
> distribution and we don't want that. I guess some smart jittering will get
> rid of the plateaus. The algorithm is VERY SLOW, so I'm afraid that coding
> it in pov SDL is completely useless!

All right, i have done some tests, the regularity does not seem to be much
of a problem, especially if you use a subset of a generated distribution. 
But the distribution is strongly anisotropic at the lower parts of the
hemisphere.  This has been mentioned in previous discussion on this
matter, it is a problem difficult to avoid if you generate the
distribution in 2d and project it on a sphere.

Thanks for sharing the code anyway.

Christoph

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

Post a reply to this message

In article <9i4a9v4nakj6for3r24ddre7uaatg0knm1@4ax.com>,
 ABX <abx### [at] abxartpl> wrote:

> Own radiosity samples distribution without recompiling.
> Own camera type without recompiling.
> Own antialiasing without recompiling.
> Own patterns via functions.
> Own ... This become a trend so I wonder what are other common purposes for
> recompiling POV which can be moved from sources to scripts (except completly 
> new features which can't be anticipated). Are there any other propositions ?

Objects. Just specify things like insideness, intersection, and normal 
functions.

Custom texture and interior attributes...just take the function pattern 
a bit further. New patterns, complete control over layered textures, etc.

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

>this can be removed ...... you need.
What do you mean exactly?

The sorting of samples is required for finding the nearest sample at any
given point withing the disc.

Post a reply to this message

Apache wrote:
> 
> >this can be removed ...... you need.
> What do you mean exactly?
> 
> The sorting of samples is required for finding the nearest sample at any
> given point withing the disc.

If you only generate the number of samples you really want to use their
order does not matter (for every direction a ray is shot, in which order
does not matter) - therefore sorting is unnecessary.

Christoph

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

Post a reply to this message

> ... the distribution is stronly anisotropic at the lower
> parts of the hemisphere.
Should the distribution isotropic then? I did my best generating a costheta
distribution, which is an anisotropic distribution. But maybe I'm completely
wrong and confused here heheheheh....... (All I want is a HUGE set of
samples that have the same quality the distribution set of the currently
official POV-Ray.)
If I would like to distribute the samples randomly but still evenly on a
(hemi)sphere, off course I wouldn't use any 2d projections onto spheres.
Using 3d math will be much more convenient in such a case IMHO.

Post a reply to this message

Agreed, but with POV-Ray doesn't use all the samples every time:
error_bound, count and minimum_reuse will limit the samples taken.

Post a reply to this message

Apache wrote:
> 
> > ... the distribution is stronly anisotropic at the lower
> > parts of the hemisphere.
> Should the distribution isotropic then? I did my best generating a costheta
> distribution, which is an anisotropic distribution.

No.  I have explained this before, the varying density does not
necessarily mean anisotropy.  Anisotropic means the density depends on the
direction on the sphere surface (in your distribution the samples are more
dense in circumference direction than in theta direction).   

Christoph

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

Post a reply to this message

Apache wrote:
> 
> Agreed, but with POV-Ray doesn't use all the samples every time:
> error_bound, count and minimum_reuse will limit the samples taken.

No.  The number of rays shot per sample does not depend on anything but
the count value.  The only thing that influences which directions from the
table are taken is that when 'normal on' is specified sample directions
behind the surface are omitted.

Christoph

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

Post a reply to this message

Now I'm really confused here... I have been thinking for years that the
count value only sets the upper limit of samples gathered and that the other
values determine when/if additional samples are taken (up to the count
value).
With very low error_bound values (like 0.1) POV-Ray generally needs much
more time to render a scene compared to very high error_bound values (like
2.5). What on earth would take POV-Ray so much time? I guess it it's
gathering more samples.....

Please explain, maybe I might learn something!

Post a reply to this message