I hope someone can help me with a problem I'm having with illuminating my
scene with flourescent lights using radiosity.

I'm re-creating my living room in pov-ray, and the problem I'm having is
with the radiosity illumination of the flourescent lights. The lights are
basically made using 160*2.5 cm cylinders with white pigment and high
ambient. A cross-section of the location of the lights in the scene is in a
kind of like this:

  ___
 /
|
| * |
|___|
|   |

I can't seem to get them to illuminate the scene enough. The real-world
lights produce sufficent lighting, but the virtual ones don't. I've cranked
the ambient value of the lights up to pow(10,30), and still the
illumination is too dark. I tried using light sources in a line instead of
high ambient, but the results didn't look very realistic. I have been
trying for 3 days to try and solve this without any luck. Here is the
radiosity block from my scene:

  radiosity {
    pretrace_start 0.08
    pretrace_end   0.4
    count 1600

    nearest_count 8
    error_bound 1.0
    recursion_limit 2

    low_error_factor 0.5
    gray_threshold 0.0
    minimum_reuse 0.015
    brightness 1

    //max_sample -1000
    adc_bailout 0.01/pow(10,30)
    //always_sample off
    //normal on
    //media on
    }

I sure would like some help with this problem. I would post comparison
images in the binary group, if I had a digital camera and the web interface
allowed attatchments.

Rohan _e_ii

Post a reply to this message

"Rohan Bernett" <rox### [at] yahoocom> wrote in message
news:web.3ddaccae46e653f8b2769afa0@news.povray.org...
> I hope someone can help me with a problem I'm having with illuminating my
> scene with flourescent lights using radiosity.
>
> I'm re-creating my living room in pov-ray, and the problem I'm having is
> with the radiosity illumination of the flourescent lights. The lights are
> basically made using 160*2.5 cm cylinders with white pigment and high
> ambient.

You could try using a high diffuse value, since that is what radiosity will
be working with instead of the ambient. Although it isn't likely to be
completely right without actual light sources.
Your error_bound might have to be 1/10 to help with blotchiness. Your count
is pretty high, seems to me anyway because I typically use a count of under
1000 or even under 500.
Why is gray_threshold at 0 (off)? Are you trying to prevent color bleed,
thus perhaps dark things into the light? Something I'm unsure would be
affective or not.
--
Farewell,
Bob

Post a reply to this message

Rohan Bernett <rox### [at] yahoocom> wrote:
> I tried using light sources in a line instead of
> high ambient, but the results didn't look very realistic.

  You shouldn't dump a possible solution just because a first experiment
didn't succeed.
  Can you be more precise about what you tried and why it didn't look good?
Did you try with area_lights (which should be quite dense and naturally
use adaptiveness)?

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

On Tue, 19 Nov 2002 18:43:42 EST, "Rohan Bernett" <rox### [at] yahoocom>
wrote:

>I can't seem to get them to illuminate the scene enough. The real-world
>lights produce sufficent lighting, but the virtual ones don't. I've cranked
>the ambient value of the lights up to pow(10,30), and still the
>illumination is too dark. 

100 should be enough, even 10, just make sure you assign the same
value to max_sample as you assign to the ambient, otherwise you're
just limiting the brightness.


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

"hughes, b." <omn### [at] charternet> wrote in message news:3ddb17cf@news.povray.org...
> Why is gray_threshold at 0 (off)? Are you trying to prevent color bleed,
> thus perhaps dark things into the light? Something I'm unsure would be
> affective or not.

gray_threshold at 0 leads to maximum colour-bleed doesn't it? Not 'off'

Andy Cocker

Post a reply to this message

How about raising recursion_limit a little? If
I'm not mistaken, thats what sets a limit for
light bouncing off of other areas (so your "light-source"
might light the lamp (limit 1) bounce off and hit another
area (limit 2), and thats it. But I could be wrong. Try raising
it to 3 or 4, maybe even 5, and see what happens...


--
Tim Nikias
Homepage: http://www.digitaltwilight.de/no_lights/index.html
Email: Tim### [at] gmxde

Post a reply to this message

"Andrew Cocker" <mai### [at] andrewcockercouk> wrote in message
news:3ddb7c87$1@news.povray.org...
>
> "hughes, b." <omn### [at] charternet> wrote in message
news:3ddb17cf@news.povray.org...
> > Why is gray_threshold at 0 (off)? Are you trying to prevent color bleed,
> > thus perhaps dark things into the light? Something I'm unsure would be
> > affective or not.
>
> gray_threshold at 0 leads to maximum colour-bleed doesn't it? Not 'off'

Oops. I think I see my mistake. I have been misinterpreting the
documentation on it. Been using very low non-zero values for it all this
time. The part where it says:

"At 0%, this feature does nothing. At 100%, you always get white/gray
ambient light, with no hue."

Obviously it must actually be saying that 0 is same as default and so makes
no change. This could need a rewording because what I think it really means
is that 0% (=0?) is that gray_threshold is not active and thereby not
applying graying. Or something to that effect.

Sure am glad you questioned me about that.

Post a reply to this message

In article <3ddb17cf@news.povray.org>,
 "hughes, b." <omn### [at] charternet> wrote:

> You could try using a high diffuse value, since that is what radiosity will
> be working with instead of the ambient. Although it isn't likely to be
> completely right without actual light sources.

Since he is using radiosity as a lighting source, the high ambient is 
needed. Diffuse won't do anything if there's no light to diffuse, your 
advice would give a black image.

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

"Christopher James Huff" <chr### [at] maccom> wrote in message
news:chr### [at] netplexaussieorg...
> In article <3ddb17cf@news.povray.org>,
>  "hughes, b." <omn### [at] charternet> wrote:
>
> > You could try using a high diffuse value, since that is what radiosity
will
> > be working with instead of the ambient. Although it isn't likely to be
> > completely right without actual light sources.
>
> Since he is using radiosity as a lighting source, the high ambient is
> needed. Diffuse won't do anything if there's no light to diffuse, your
> advice would give a black image.

I see, thanks Christopher. I almost mentioned ambient 1 instead of very high
ambient values because I wasn't sure how the higher than 1 value might
negatively affect the outcome of the render.
--
Farewell,
Bob

Post a reply to this message

"Rohan Bernett" <rox### [at] yahoocom> wrote in
news:web.3ddaccae46e653f8b2769afa0@news.povray.org 

[...]

I alsow played with pure-ambient lights, but there are terribly slow to 
render.

In my case the solution was - to use assumed_gamma 1.0 (or even 0.7)
Other thing - swith for a test all textures to pigment rgb .9 and difffuse 
.8 or .9

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

"Tim Nikias" <tim### [at] gmxde> wrote in news:3ddba725@news.povray.org

> How about raising recursion_limit a little? If
> I'm not mistaken, thats what sets a limit for
> light bouncing off of other areas (so your "light-source"
> might light the lamp (limit 1) bounce off and hit another
> area (limit 2), and thats it. But I could be wrong. Try raising
> it to 3 or 4, maybe even 5, and see what happens...

Oh yes - I  forgot - this also is very importent, even using 9 or 10 may be 
a must to get proper results.


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

Rafal 'Raf256' Maj wrote:
>"Tim Nikias" <tim### [at] gmxde> wrote in news:3ddba725[at]news.povray.org
>
>> How about raising recursion_limit a little? If
>> I'm not mistaken, thats what sets a limit for
>> light bouncing off of other areas (so your "light-source"
>> might light the lamp (limit 1) bounce off and hit another
>> area (limit 2), and thats it. But I could be wrong. Try raising
>> it to 3 or 4, maybe even 5, and see what happens...
>
>Oh yes - I  forgot - this also is very importent, even using 9 or 10 may be
>a must to get proper results.

I've tried bumping it all the way up to 20 and STILL the scene is too dark!

I'll try a couple of the suggestions in the thread and see how they go.
Hopefully they won't make the scene unbearably slow. As we all know, an
extremely slow radiosity scene is a real pain when trying to test renders
of it, particulary when using radiosity lighting like this one. The
finished scene will also include some standard lights for other light
sources present in the scene.

Sorry about not posting any replies for so long, but I'm on uni holidays at
the moment and don't get onto the internet very often during the holidays.

Rohan _e_ii

Post a reply to this message

I've just tried a couple of the suggestions and the scene is a bit brighter,
but still a bit too dark. I'd say it still needs to be about 10% brighter
(judging from some fiddling with the image in Paint Shop Pro). Unfortunatly
the scene is still very blotchy even with these settings:

  radiosity {
    pretrace_start 0.08
    pretrace_end   0.4
    count 1600

    nearest_count 2
    error_bound 0.9
    recursion_limit 20

    low_error_factor 0.5
    gray_threshold 0.0
    minimum_reuse 0.015
    brightness 1

    max_sample pow(10,30)
    adc_bailout 0.01/pow(10,3)
    //always_sample off
    //normal on
    //media on
    }

Any ideas?

Rohan _e_ii

Post a reply to this message

On Mon, 25 Nov 2002 21:20:35 EST, "Rohan Bernett" <rox### [at] yahoocom>
wrote:

>I've just tried a couple of the suggestions and the scene is a bit brighter,
>but still a bit too dark. I'd say it still needs to be about 10% brighter
>(judging from some fiddling with the image in Paint Shop Pro). Unfortunatly
>the scene is still very blotchy even with these settings:

>  radiosity {
>    pretrace_start 0.08
>    pretrace_end   0.4

Why in the world are you using a pretrace_end larger than your
pretrace_start?! How is POV supposed to reduce the step size in this
case? Anyway, I would use pretrace_start 1 pretrace_end 1/512 if I
were really desperate

>    count 1600

Unless you're doing something extremely complex or extremely wrong,
this is definitely overkill!

>    nearest_count 2

Personally, I never go below 10. And that's the maximum. Of course,
your mileage may vary, but expect blotchiness with such a low setting.

>    error_bound 0.9
>    low_error_factor 0.5

That's quite high if you really have a lack of samples problem. I'd
use 0.5 for the pretraces and 0.3 for the final pass.

>    recursion_limit 20

Again, overkill. Unless you're doing something completely wrong,
you're just wasting your computer's time.

>    max_sample pow(10,30)
>    adc_bailout 0.01/pow(10,3)

That's just slowing things down. Use a max_sample equal to the
brightness of your object. If you really are using an ambient of a
decillion, you're definitely on the wrong track, and of course you're
going to run into precision problems.

>    //always_sample off

Maybe leave it on, as it seems you have a lot of time on your hands :)


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

> >    nearest_count 2
>
> Personally, I never go below 10. And that's the maximum. Of course,
> your mileage may vary, but expect blotchiness with such a low setting.

Actually the max is 20.  During beta, the docs still said 10 (even though
the max was 20 then as well), but they appear to have been updated for the
release.

-tgq

Post a reply to this message

On Tue, 26 Nov 2002 08:20:33 -0500, "TinCanMan"
<Tin### [at] hotmailcom> wrote:

>Actually the max is 20.  During beta, the docs still said 10 (even though
>the max was 20 then as well), but they appear to have been updated for the
>release.

10x for the heads-up.


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

Rohan Bernett wrote:
>I've just tried a couple of the suggestions and the scene is a bit brighter,
>but still a bit too dark. I'd say it still needs to be about 10% brighter
>(judging from some fiddling with the image in Paint Shop Pro). Unfortunatly
>the scene is still very blotchy even with these settings:
>
>  radiosity {
>    pretrace_start 0.08
>    pretrace_end   0.4
>    count 1600
>
>    nearest_count 2
>    error_bound 0.9
>    recursion_limit 20
>
>    low_error_factor 0.5
>    gray_threshold 0.0
>    minimum_reuse 0.015
>    brightness 1
>
>    max_sample pow(10,30)
>    adc_bailout 0.01/pow(10,3)
>    //always_sample off
>    //normal on
>    //media on
>    }
>
>Any ideas?

Why don't you just raise the brightness value? That's what I do in most of
my radiosity scenes. Recursion limit 20... are you MAD? :-) crop it to 2,
or 3, and try brightness 2, 3... oh and usually it's pretrace_start >=
pretrace_end.
And don't forget to lower your error_bound to something like, say, 0.1.
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*/
}




--
Jonathan

Post a reply to this message

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

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

Then somebody should explain why they want their rays to be more
dense at the normal.
Especially with respect to your challenge below ;-)

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

How was the built-in array created? (I would like to know,
which quality I have to beat). In fact you already mentioned,
that you want the same quality contraints for initial segments
of the array, so my earlier suggestion might already do the trick.

  Mark

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?

Am posting examples in p.b.i.

  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?

What you must remember is that you are trying to estimate the lighting 
at a particular point.

If you have a light source almost tangential to the surface it doesn't 
illuminate much and one almost normal to the surface gives high 
illumination. So, if all the samples are weighted the same you want most 
samples from the normal direction and few from tangential to give the 
best estimate.

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

I suppose it could be, and I've thought about doing this. However you 
would have to calculate an array for each level of radiosity recursion 
because the code reduces the number of samples taken at each subsequent 
recursion level. And the results wouldn't be very different anyway.

> 
>   Mark

Mike Andrews.

Post a reply to this message

On Fri, 29 Nov 2002 15:01:24 +0100, Mark Weyer
<wey### [at] fregemathematikuni-freiburgde> wrote:

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

Probably for the same reason most other jitters use fixed arrays - for
true platform independence (at least that's how I read it).


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

Hi Christoph,

The cos-theta distribution on the hemisphere is given by creating an 
even distribution on a unit circle and then projecting up or down to a 
unit hemisphere.

You can see this by taking a copy of the radiosity sample array, editing 
it to pov syntax and including it in a small scene which puts a sphere 
at the <X,Y,0> points. If you do an animation which adds 1 or a few 
sample positions each frame you can see how the distribution builds up.

Mike Andrews.

Christoph Hormann wrote:
> 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
>

Post a reply to this message

Mark Weyer wrote:
> 
> [...]
> 
> How was the built-in array created? (I would like to know,
> which quality I have to beat). In fact you already mentioned,
> that you want the same quality contraints for initial segments
> of the array, so my earlier suggestion might already do the trick.

You don't need to know how the original distribution was created to
compare quality.  If you follow the link i posted you will find several
measurements of the quality of distributions.  Apart from the maximum
uniformity the distribution should not be regular to be well suited for
radiosity sampling.

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

Michael Andrews wrote:
> 
> Hi Christoph,
> 
> The cos-theta distribution on the hemisphere is given by creating an
> even distribution on a unit circle and then projecting up or down to a
> unit hemisphere.
> 
> [...]

It is fairly possible that this is the method how the directions array was
originally created but there is no way how to prove this.

Another method (which probably produces higher quality for a fixed number
of rays if done well) would be a repulsion algorithm with a non uniform
force field (i.e. higher repulsive forces between the points at low angle)

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

> If you have a light source almost tangential to the surface it doesn't
> illuminate much and one almost normal to the surface gives high
> illumination. So, if all the samples are weighted the same you want most
> samples from the normal direction and few from tangential to give the
> best estimate.

Ok, that explains it. As a purist I was assuming you take an
even distribution and weight the samples with cos. But it would
be hard to sell that to running-time-theists...

> I suppose it could be, and I've thought about doing this. However you
> would have to calculate an array for each level of radiosity recursion
> because the code reduces the number of samples taken at each subsequent
> recursion level. And the results wouldn't be very different anyway.

The way Christoph was putting it, you reuse an initial segment of the
array. My current approach would be to build in a precomputed array
for everyday use with the possibility to replace it by something larger.

  Mark

Post a reply to this message

> > The cos-theta distribution on the hemisphere is given by creating an
> > even distribution on a unit circle and then projecting up or down to a
> > unit hemisphere.
> [...]
> Another method (which probably produces higher quality for a fixed number
> of rays if done well) would be a repulsion algorithm with a non uniform
> force field (i.e. higher repulsive forces between the points at low angle)

I do not see why the quality is better than using repulsion
inside the unit circle with a uniform force field before projecting.

  Mark

Post a reply to this message

Mark Weyer wrote:
> 
> I do not see why the quality is better than using repulsion
> inside the unit circle with a uniform force field before projecting.

To me it seems fairly obvious that projecting a disc on a hemisphere does
not maintain the distance relations and therefore reduces the uniformity
of a distribution.  

To be precise, the points at the rim of the hemisphere will be quite dense
in direction of the circumference but will be moved apart in theta
direction.

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:
> 
> Mark Weyer wrote:
> 
>>I do not see why the quality is better than using repulsion
>>inside the unit circle with a uniform force field before projecting.
> 
> 
> To me it seems fairly obvious that projecting a disc on a hemisphere does
> not maintain the distance relations and therefore reduces the uniformity
> of a distribution.  

The point is that you do not want a uniform distribution on the 
hemisphere ...

> 
> To be precise, the points at the rim of the hemisphere will be quite dense
> in direction of the circumference but will be moved apart in theta
> direction.

Ahh! If you used a unit circle to do the repulsion thing then you are 
quite right - you do not get an even distribution at the edge: all the 
outermost points would be pressed against the rim.

This is why I used a 2 radius circle when I was doing the Delaunay 
triangulation, and adding samples until I had enough in the unit circle. 
That way you get an even distribution right across the unit circle - 
right to the rim of the hemisphere.

You could do the same with a repulsion algorithm - fill a circle of 
greater than 1 radius and keep adding a sample and repelling to 
completion untill you have the right number of samples within the 1 unit 
circle.

> 
> Christoph
> 

Mike Andrews.

Post a reply to this message

Michael Andrews wrote:
> 
> [...]
> 
> Ahh! If you used a unit circle to do the repulsion thing then you are
> quite right - you do not get an even distribution at the edge: all the
> outermost points would be pressed against the rim.
> 
> This is why I used a 2 radius circle when I was doing the Delaunay
> triangulation, and adding samples until I had enough in the unit circle.
> That way you get an even distribution right across the unit circle -
> right to the rim of the hemisphere.

The radius of the circle does not matter, once you project it on a
hemisphere you get an anisotropic distribution (meaning the density of the
points depends on the direction like explained in my last post).  But feel
free to try it out, i'm sure if you check the quality of the results you
will 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

Christoph Hormann wrote:
> The radius of the circle does not matter, once you project it on a
> hemisphere you get an anisotropic distribution (meaning the density of the
> points depends on the direction like explained in my last post).  But feel
> free to try it out, i'm sure if you check the quality of the results you
> will see it.

This anisotropy is inevitable - the density of the samples is decreasing 
  with theta but constant in phi. If you plot the radiosity sample 
positions you can see this quite clearly with the official samples.

> 
> Christoph
> 

Mike Andrews.

Post a reply to this message

Rohan Bernett wrote:
>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.

Which sounds reasonably fast... esp. if you consider that these ones could
serve as not too bad settings for the final render.

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

hmm I've waited hours for 320x240 test renders (and we all know of users who
wait days for that)... what's the matter? When I build up a scene, I use a
simpler lighting setup, no radiosity (or very low settings), no reflections
etc. As soon as the final render begins, it could last days, I couldn't
care less (as long as the scene is worth it...)

>I hate slow renders.

Everybody does, but remember, first comes quality.

--
Jonathan

Post a reply to this message

> Ahh! If you used a unit circle to do the repulsion thing then you are
> quite right - you do not get an even distribution at the edge: all the
> outermost points would be pressed against the rim.
> 
> This is why I used a 2 radius circle when I was doing the Delaunay
> triangulation, and adding samples until I had enough in the unit circle.
> That way you get an even distribution right across the unit circle -
> right to the rim of the hemisphere.

I am uneasy about this. I fear you do not solve the problem
but only make it less visible by moving the edge farther out.
I would prefer doing the thing without any edges at all: Use
the unit square as a torus, find an even distribution there,
map it onto the unit circle via
  phi <- 2*pi*x
  r <- sqrt(y)
and then proceed as you suggested.

  Mark

Post a reply to this message

Michael Andrews wrote:
> I suppose it could be, and I've thought about doing this. However you 
> would have to calculate an array for each level of radiosity recursion 
> because the code reduces the number of samples taken at each subsequent 
> recursion level. And the results wouldn't be very different anyway.

I've had another think about this, and I don't think it would work in 
some cases.

The code uses the apparent (texture modified) surface normal and checks 
whether a particular sample can be used or is going behind the actual 
surface. If the sample can not be used then it takes a fresh sample.

So you can not know a priori how many samples you need at a particular 
recursion level because it may alter at each sampling point.

This is why you not only need an even sample distribution but also to 
have the distribution as even as possible over the first N samples of 
the distribution where N can be any number up to the maximum possible 
number of samples.

And this is why I was looking at an iterative Delaunay triangulation - 
to get a 'good enough' even distribution for the first N samples of the 
distribution.

For something like a repulsion algorithm which sets the position of all 
the sample points at once you would then need to choose the sampling 
order carefully to get a good distribution for any number of points.

Enough babbling ...

Bye for now,
	Mike Andrews.

Post a reply to this message

Michael Andrews wrote:
> 
> [...]
> 
> This is why you not only need an even sample distribution but also to
> have the distribution as even as possible over the first N samples of
> the distribution where N can be any number up to the maximum possible
> number of samples.

Exactly, like i said in

news://news.povray.org/3DE76813.8B1CB162%40gmx.de

> For something like a repulsion algorithm which sets the position of all
> the sample points at once you would then need to choose the sampling
> order carefully to get a good distribution for any number of points.

Yes, that's the idea how to do it.  Generate a number of point using an
arbitrary algorithm (but chosen for a uniform but non-regular
distribution) and then sort them for maximum uniformity at lower sample
counts too.  I can't think think of a different method that does not
produce a regular distribution.

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

>hmm I've waited hours for 320x240 test renders (and we all know of users who
>wait days for that)

Man is that slow!

>When I build up a scene, I use a
>simpler lighting setup, no radiosity (or very low settings), no reflections
>etc.

I don't think I can simplify my lighting setup. I only have the neccessary
number of light sources to match the locations in the real world scene. As
for no radiosity, for the flouro lights that's a no-can-do.

>As soon as the final render begins, it could last days, I couldn't
>care less (as long as the scene is worth it...)

Only if you have a second computer to handle the slow rendering.

As for test renders, hours or days is far too long. For test renders, 10
minutes is getting too slow, I'd definatly prefer 30 second test renders.

I should probably stop grumbling and go and read a different thread now.

Rohan _e_ii

Post a reply to this message

On Wed,  4 Dec 2002 03:51:07 EST, "Rohan Bernett" <rox### [at] yahoocom>
wrote:

>As for test renders, hours or days is far too long. For test renders, 10
>minutes is getting too slow, I'd definatly prefer 30 second test renders.

I think you should either stick to simple scenes or use another
program :) But even in "fast" renderers like MAX, a scene with
raytraced soft shadows, reflections, radiosity and so on will not fall
within your expectations of a render time.


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

>I think you should either stick to simple scenes or use another
>program :) But even in "fast" renderers like MAX, a scene with
>raytraced soft shadows, reflections, radiosity and so on will not fall
>within your expectations of a render time.

Lucky for me I'm using soft shadows, reflections and radiosity, yet.
Although by the time I get to the final render, I probably will be. That'll
probably mean a render of several days, given the ambitious complexity of
the intended final scene.

Rohan _e_ii

Post a reply to this message