git### [at] wanadoofr news:3f0dd15b@news.povray.org

>> > Recursion limit:  1
>> 3..5 or more
> This is definitely overkill. For practical purposes, recusion is not a
> measure of quality. Most scenes look good enough with recursion 1,
> many can 

I dissagree, I usualy use 4-5. It is very important in some scenes - for 
quick example imagin a maze with a light source far away, but with very 
white walls like rgb .9 diffuse .9

ascii art :

####### ########
<)    # #      #
##### ###  ### #
    #      # # #
    ######## # #
            #   #
            # * # <- light source 
            ##### 
in scene as above with recursion limit 4 image will be 100% black, and with 
recursion ~10 it will be o.k.

using adc_bailout 1/128 will prevent "overkill" :) and it is not broken.



-- 
#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" <spa### [at] raf256com> wrote in message
news:Xns### [at] 204213191226...
> git### [at] wanadoofr news:3f0dd15b@news.povray.org
>
> >> > Recursion limit:  1
> >> 3..5 or more
> > This is definitely overkill. For practical purposes, recusion is not a
> > measure of quality. Most scenes look good enough with recursion 1,
> > many can
>
> I dissagree, I usualy use 4-5. It is very important in some scenes - for
> quick example imagin a maze with a light source far away, but with very
> white walls like rgb .9 diffuse .9
>
> ascii art :
>
> ####### ########
> <)    # #      #
> ##### ###  ### #
>     #      # # #
>     ######## # #
>             #   #
>             # * # <- light source
>             #####
> in scene as above with recursion limit 4 image will be 100% black, and
with
> recursion ~10 it will be o.k.
>
> using adc_bailout 1/128 will prevent "overkill" :) and it is not broken.
>
>
>
> --
> #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


    When you use 4 or 5 recursion limit, the time it takes to render must be
VERY long.  When I put it up that high EACH big square of the radiosity map
thing took like 30 seconds to a minute to render.

Post a reply to this message

To get back to the topic though, anyone else know how I might
reduce artifacts?  I have tried what raf said but I am still having major
problems.  Other scenes that I have rendered using lights as my main sorce
or illumination I have had no problem eliminating them(artifacts), but it
seems that the scenes in where I try to light up the space with mostly
radiosity generated light it is just blotchy or patterns develope on the
wall that won't go away.

Post a reply to this message

On Thu, 10 Jul 2003 20:51:40 -0700, "ran102" <mon### [at] stinet> wrote:
> To get back to the topic though, anyone else know how I might
> reduce artifacts?

Have you tried your scene with predefined settings located in rad_def.inc
standard include file ? http://www.povray.org/documentation/view/287/

ABX

Post a reply to this message

Xns### [at] 204213191226...
> git### [at] wanadoofr news:3f0dd15b@news.povray.org
> I dissagree, I usualy use 4-5. It is very important in some scenes - for
> quick example imagin a maze with a light source far away, but with very
> white walls like rgb .9 diffuse .9

Of course, you can build a scene so that it requires a high level of
recursivity, just like you can build a scene that requires max_trace_level
256 or any other feature set at its maximum level. But it still doesn't make
sense for scenes that won't use it.

> using adc_bailout 1/128 will prevent "overkill" :) and it is not broken.
You're right (and Warp is right too), it's the adc_bailout in reflection and
refraction that's broken (it's in a p.general thread of 12/3/2003 but I
couldn't find it yesterday).

In any case, I'd certainly be interested in demo scenes that would
demonstrate the use of high recursion levels associated with variable values
of adc_bailout, while keeping reasonable render times and quality.

G.

--

**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters

Post a reply to this message

>          To get back to the topic though, anyone else know how I might
> reduce artifacts?  I have tried what raf said but I am still having major
> problems.  Other scenes that I have rendered using lights as my main sorce
> or illumination I have had no problem eliminating them(artifacts), but it
> seems that the scenes in where I try to light up the space with mostly
> radiosity generated light it is just blotchy or patterns develope on the
> wall that won't go away.

good settings for radiosity is quite scene dependant. If you want you can
post your scene file .pov in povray.binaries.scene-files or
povray.text.scene-files and I'll be happy to do some tests with it

M

Post a reply to this message

3f0e344e@news.povray.org...
> it seems that the scenes in where I try to light up the space with mostly
> radiosity generated light it is just blotchy or patterns develope on the
> wall that won't go away.

In addition to what Mael said, there are unfortunately many situations where
it's difficult to avoid artifacts completely. Scenes involving large
expanses of walls are typically problematic...
Some people have tried to change the code to allow more than 1600 samples,
with partial success. The original developer of the radiosity code, Jim
McElhiney, reported recently in p.programming that there were some problems
in it (bad news) but that he was trying to fix them (good news).

G.

--

**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters

Post a reply to this message

mon### [at] stinet news:3f0e344e@news.povray.org

>    To get back to the topic though, anyone else know how I might
> reduce artifacts?  I have tried what raf said but I am still having major


Email sources to me at pov (at) raf256 -dot- com if You wish. 



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

Thanks everyone for the good advice.  I'll post the scene file in the
povray.binaries.scene.file.  Thank you.  Also, yes I've read the povray
documentation many times about radiosity.  That is very interesting about
the guy who made the radiosity code.
>
>

Post a reply to this message

In article <Xns### [at] 204213191226>, spa### [at] raf256com 
says...
> git### [at] wanadoofr news:3f0dd15b@news.povray.org
> 
> >> > Recursion limit:  1
> >> 3..5 or more
> > This is definitely overkill. For practical purposes, recusion is not a
> > measure of quality. Most scenes look good enough with recursion 1,
> > many can 
> 
> I dissagree, I usualy use 4-5. It is very important in some scenes - for 
> quick example imagin a maze with a light source far away, but with very 
> white walls like rgb .9 diffuse .9
> 
> ascii art :
> 
> ####### ########
> <)    # #      #
> ##### ###  ### #
>     #      # # #
>     ######## # #
>             #   #
>             # * # <- light source 
>             ##### 
> in scene as above with recursion limit 4 image will be 100% black, and with 
> recursion ~10 it will be o.k.
> 
> using adc_bailout 1/128 will prevent "overkill" :) and it is not broken.
> 
> 

You sure this isn't 'normal'? There are examples of this sort of maze 
that are built to intentionally minimize refraction and will as a result 
'always' appear black from the camera location in the real world. Adding 
levels of recursion to it to 'make it work right' is in such cases likely 
wrong anyway.

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message