Hi Rohan,

I haven't been able to get good results using small radiosity 'light' 
sources. Even with 1600 samples the source can be missed. Also, because 
of the way the samples are taken, the places where the source is hit 
tend to be the same size and shape as the source.

To get a better image I had to fiddle with the radiosity code. Now, each 
time the code starts taking samples at a point it chooses a random angle 
and rotates the sample directions around the surface normal by this amount.

This has the effect of losing the low-frequency noise but gaining higher 
-frequency noise, most visible in tight spaces and corners. I think this 
is more advantageous than not, but I'll have to produce a patch that 
lets the user choose which method to use in a scene ...

I'll post a pair of comparison images on p.b.i and the scene on p.b.s-f 
shortly.

Bye for now,
	Mike Andrews.

Post a reply to this message

Michael Andrews wrote:
> 
> Hi Rohan,
> 
> I haven't been able to get good results using small radiosity 'light'
> sources. Even with 1600 samples the source can be missed. Also, because
> of the way the samples are taken, the places where the source is hit
> tend to be the same size and shape as the source.
> 
> To get a better image I had to fiddle with the radiosity code. Now, each
> time the code starts taking samples at a point it chooses a random angle
> and rotates the sample directions around the surface normal by this amount.

Sounds logical, avoiding regular patterns by randomizing the sampling
directions without breaking their uniform distribution.

How much speed does this additional rotation cost?

One bad side effect would be the results will differ depending on the
tracing situation, a bit like jitter, which will lead to problems in
animations.

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

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). 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.
> 
> 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.
> 
> One bad side effect would be the results will differ depending on the
> tracing situation, a bit like jitter, which will lead to problems in
> animations.

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

Mike Andrews.

Post a reply to this message

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

JRG wrote:

>So run POV-Ray and try something like:
>radiosity {
>pretrace_start 0.08
>pretrace_end 0.01
>count 300
>error_bound 0.1
>recursion_limit 2
>brightness 2 /*3... you may want to tune this value together with the
>brightness of your source*/
>}

I tried these settings and the scene slowed down terribly. As I'm writing
this, the render has been going 56min and is only on line 258. The lo-res
preview and what's done so far looks pretty good, although there are some
odd blotches near the light sources.

I hate having to wait ages for just a test render. I think anything over 5
minutes for an 800*600 image with no AA, is too slow.

I hate slow renders.

Rohan _e_ii

Post a reply to this message

Rohan Bernett wrote:

> I hate having to wait ages for just a test render. I think anything over 5
> minutes for an 800*600 image with no AA, is too slow.

If that is the case then you are using the wrong program.
May suggest MS paint instead?

-- 
Ken Tyler

Post a reply to this message

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

What is the problem you are adressing here?

My assumption (1-dimensional version): A sequence of numbers
between 0 and 1 such that for each initial segment of the sequence
the density is fairly even throughout the interval.

This can be done by choosing an irrational number r and taking the
sequence a(n)=(n*r) mod 1. The optimal r then is the golden ratio,
i.e. r=(sqrt(5)-1)/2.

Two dimensional version: here we take two such sequences, to two
irrational numbers r1 and r2. Those have to be independent in the
sense that 1, r1 and r2 are linear independent in the vector space
of the real numbers over the field of the rational numbers. While
it is easy to find such r1, r2, I do not know which give the best
results (in the same sense that the golden ration is optimal above).

The final version: So far we have a continuing uniformly distributed
sequence in the unit square. We have to map this to the hemisphere
without loosing uniformity. This can be achieved by

  (x,y) -> (sin(2pi*x)*sqrt(1-y^2),cos(2pi*x)*sqrt(1-y^2),y)

Regards,

  Mark

Post a reply to this message

Mark Weyer wrote:
> 
> > Well, it is not easy to create such a continuously uniform distribution,
> > uniform at a certain number is fairly simple on the other hand.
> 
> What is the problem you are adressing here?
> 
> [...]

Quoting from the source:

A bit of theory: The goal is to create a set of "random" direction rays
so that the probability of close-to-normal versus close-to-tangent rolls
off in a cos-theta curve, where theta is the deviation from normal.
That is, lots of rays close to normal, and very few close to tangent.
You also want to have all of the rays be evenly spread, no matter how
many you want to use.  The lookup array has an array of points carefully
chosen to meet all of these criteria.

The problem is similar to the classical "How can I arrange N points evenly
on a sphere" problem like described in:

http://www.ogre.nu/sphere.htm

Just that it is hemispherical, not really uniform and it not only has to
be good for N points but also for N-X points (X = 1..N-1)

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

> A bit of theory: The goal is to create a set of "random" direction rays
> so that the probability of close-to-normal versus close-to-tangent rolls
> off in a cos-theta curve, where theta is the deviation from normal.
> That is, lots of rays close to normal, and very few close to tangent.
> You also want to have all of the rays be evenly spread, no matter how
> many you want to use.  The lookup array has an array of points carefully
> chosen to meet all of these criteria.

That's what I thought, except I expected the probability to be
sin(theta)
(or cos(theta), if theta is the angle between ray and TANGENT), implying
fewer rays close to normal than close to tangent. Is this a typo?

Why is the lookup array fixed? It might be calculated at program start,
allowing for varying length.

  Mark

Post a reply to this message

Mark Weyer wrote:
> 
> [...]
> 
> That's what I thought, except I expected the probability to be
> sin(theta)
> (or cos(theta), if theta is the angle between ray and TANGENT), implying
> fewer rays close to normal than close to tangent. Is this a typo?

I don't think so.

> Why is the lookup array fixed? It might be calculated at program start,
> allowing for varying length.

I'm sure if you come op with a method to generate a high quality
distribution within a fraction of a second or so everyone would be eager
to see it...

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