Michael Andrews wrote:
> 
> Christoph Hormann wrote:
> > Sounds logical, avoiding regular patterns by randomizing the sampling
> > directions without breaking their uniform distribution.
> 
> Have you ever actually looked at the sample distribution? It's only
> truely uniform at very specific sample numbers (51, 100-and-something,
> roughly doubling to 1600).

Well, it is not easy to create such a continuously uniform distribution,
uniform at a certain number is fairly simple on the other hand.

> I've been playing with a couple of algorithms
> to see if I could get a 'good enough' sampling at any number. The best
> I've found is using the Delaunay triangulation of a 2 unit radius disk
> and adding a new sample at the center of the largest circumcircle until
> there are 1600 samples within the 1 unit disk. Gives a reasonable
> distribution at all sample numbers.

I don't see how this creates a hemispherical distribution, sounds
two-dimensional.

> >
> > How much speed does this additional rotation cost?
> 
> It's only a handfull of adds and multiplies, a sin() and a cos() each
> time ra_gather() is called. Compared to the rest of the radiosity code
> it is negligible.

This i can imagine myself :-), i was interested in the actual render
times.

> Yes, but radiosity already had a random jitter in it, added in
> Start_Tracing_Radiosity_Preview() at around line 1040 in render.cpp. In
> fact I've taken this jitter out in my version to see what difference it
> made. In the scenes I've tried it doesn't seem to make much difference,
> but I can think of some where it would, so I may put it back in.

I suppose it does not have much effect in most cases (at least much less
than a rotation of sampling directions like you described), and it only
affects the pretrace so rendering without pretrace resolves the problem.

Christoph

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

Post a reply to this message