"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