I was building a scene to play with Kari Kivisalo's more accurate light
source ideas (as on his 'dynamic range compression' page) when I hit
a(nother) radiosity quirk. Fortunately I'd found a fix for it before I
found the bug!!

This is actually the bug that I thought my previous bug report was
finding: because the radiosity sample counter is reset to the start
every time, sampling artifacts are produced.

To show this I've posted two images in p.b-t.b: the first is with
WinPoV-Ray v3.5b6, the second is with a modified MegaPoV compile. The
vertical shadings on the wall by the light pannel and the fan shadings
on the floor in the v3.5 image are caused by the 'bug'.

The fix is easy: put in another count variable in ra_gather which is
either (local) static or randomly set on entry and incremented in the
sampling loop. Using this to index the rad_samples array removes the
sampling bias.

I'll append the scene file to this message.

Bye for now,
	Mike Andrews.

//#version unofficial MegaPov 0.7;

// +w320 +h240 +a0.3

global_settings { 
  max_trace_level 5
  assumed_gamma 1
  ambient_light 1
  adc_bailout 0
#if(1)
//  ini_option "+QR"
  radiosity {
    pretrace_start 8/image_width
    pretrace_end   4/image_width
    error_bound 0.1
    low_error_factor 0.1
    count 183
    recursion_limit 1
  }
#end
}                                                                       

camera {
  location  <4.0, 1.65, -4.5>
  direction z  
  right     x*image_width/image_height
  look_at   <3.5,1,-2> 
}

box { 0, <5,5,-5> inverse
  pigment { rgb 0.8 }
  finish { ambient 0 diffuse 0.7 specular 0.2 }
}

#declare C = 0; #while (C < 3)
  box { 0, 1
    pigment {
      planar 
      rotate 90*x 
      colour_map {
        [0.1 rgb vaxis_rotate(<.9,.3,.3>, 1, C*120)]
        [0.1 rgb 1]
      } 
    }
    finish { ambient 0 diffuse 0.6 specular 0.2 }
    translate -(x+z)/2
    scale <0.2,1.5,0.01>
    translate <2.1+C*0.4,0,-2>
  }
#declare C = C + 1; #end

#declare C = 0; #while (C < 4)
  box { 0, 1
    pigment { rgb 1 }
    finish { ambient 0 diffuse 0.8 specular 0.2 }
    translate -(x+z)/2
    scale <0.2,2.5,0.01>
    translate <1.9+C*0.4,0,-1.7>
  }
#declare C = C + 1; #end

#declare sX = 1;
#declare sY = 1;
#declare N = 2;
#declare cL = <2.5,1.5,-0.005>; 

box { -<sX/2,sY/2,0.01>, <sX/2,sY/2,0.01>
  pigment { rgb 1 }
  finish { ambient 1 diffuse 0 }
  translate <cL.x,cL.y,0>
  no_shadow
}

#declare C1 = 0; #while (C1 < N)
  #declare C2 = 0; #while (C2 < N)
    light_source {
      0, rgb 10
      area_light x*sX/N, y*sY/N, 4, 4 jitter
      spotlight
      radius -90 falloff 90
      point_at -1000*z
      fade_power 2
      fade_distance sqrt(sX*sY)/N
      translate <sX*((C1+0.5)/N-0.5), sY*((C2+0.5)/N-0.5), 0> + cL
    }
  #declare C2 = C2 + 1; #end
#declare C1 = C1 + 1; #end

Post a reply to this message

Michael Andrews wrote:
>
> because the radiosity sample counter is reset to the start
> every time, sampling artifacts are produced.

Excellent! Could you render cornell.pov with the old and modified
MP so that the effect of the fix on overall energy distribution can
be compared.

>       fade_distance sqrt(sX*sY)/N
                      ^^^^
You fixed this too :)
 
_____________
Kari Kivisalo

Post a reply to this message

Hi Kari,

Kari Kivisalo wrote:
> 
> Michael Andrews wrote:
> >
> > because the radiosity sample counter is reset to the start
> > every time, sampling artifacts are produced.
> 
> Excellent! Could you render cornell.pov with the old and modified
> MP so that the effect of the fix on overall energy distribution can
> be compared.

I'm posting the same file run on original MegaPov, my modified MegaPov
and v3.5b6. I'll put them as a reply to my previous post on p.b-t.b.

There seems to be a major fix on the spotlight code between MegaPov and
3.5; there is a very marked difference at the top of the walls between
the two.

> 
> >       fade_distance sqrt(sX*sY)/N
>                       ^^^^
> You fixed this too :)

Well this looked like a way to do non-square lights. I'll probably
modify the scene to allow different numbers of light patches in each
direction. This would probably need 

	fade_distance sqrt((sX*sY)/(nX*nY))

I guess.

> 
> _____________
> Kari Kivisalo

Bye

Post a reply to this message

Michael Andrews wrote:
>
> I'm posting the same file run on original MegaPov, my modified MegaPov
> and v3.5b6. I'll put them as a reply to my previous post on p.b-t.b.

Thanks.

There are less artefacts but the ceiling and front side of the small
box differ visibly. I would have expected the new image to more closely
match the Cornell reference image but it doesn't. Maybe some other
part of the code relies on the samples being taken the old way.
 
> There seems to be a major fix on the spotlight code between MegaPov and
> 3.5;

This why I had to use strange tightness value to get something
close to cosine falloff from MP spotlight.

_____________
Kari Kivisalo

Post a reply to this message

"Kari Kivisalo" <ray### [at] engineercom> wrote...
> Michael Andrews wrote:
> >
> > I'm posting the same file run on original MegaPov, my modified MegaPov
> > and v3.5b6. I'll put them as a reply to my previous post on p.b-t.b.
>
> Thanks.
>
> There are less artefacts but the ceiling and front side of the small
> box differ visibly. I would have expected the new image to more closely
> match the Cornell reference image but it doesn't. Maybe some other
> part of the code relies on the samples being taken the old way.

I think that the samples were generted and chosen in a specific order to
produce the best sampling with the fewest samples.  Also, the artifacts are
at least somewhat desired, since they smooth out the noise in the image.
Low-frequency noise is less perceptible to the human eye than high-frequency
noise.  Using the same set of sample vectors for each sample point yeilds
artifiacts and low-frequency noise, while using fully random sample vectors
produces high-frequency noise.

-Nathan

Post a reply to this message