well, this is an interesting one.

the bug itself isn't in the new code; it is just being highlighted by the
block rendering we do. it even happens in single-thread mode, which means it
must be related to the horizontal extent of a render since that's the only
change in the order of pixels between the classic rendering and the new block
rendering when there is only one thread. And indeed if I set the block size
to 1x1 or to the render width, the results between 3.6 and 3.7 are identical.

The code must have some dependancy on the order in which parts of the surface
are probed. Take this scene for example:

//---------------------------------------------------------------------------

global_settings
{
  assumed_gamma 2.2
  max_trace_level 6
}

light_source { <-1, 1, -1> color rgb 1.0*0.5 shadowless }
light_source { <0, 1, 1> color rgb 1.0*0.5 shadowless }
light_source { <1, 1, -1> color rgb 1.0*0.5 shadowless }
light_source { <0, 1, -5> color rgb 0.75 shadowless }
light_source { <0, -1, -5> color rgb 0.75 shadowless }

camera {
  location    <0, 1, -3>
  look_at     <0, 0, 0>
}

sky_sphere {
  pigment {
    gradient y
    color_map {
      [0.0 rgb <0.6,0.7,1.0>]
      [1.0 rgb <0.2,0.2,0.8>]
    }
  }
}

plane
{
  y, -1.25
  pigment { colour rgbft <0,1,0,0,0> }
  finish { reflection { 1 } }
  no_reflection
}

plane
{
  x, -1.25
  pigment { colour rgbft <0,0,1,0,0> }
  finish { reflection { 1 } }
  no_reflection
}

plane
{
  x, 1.25
  pigment { colour rgbft <1,0,0,0,0> }
  finish { reflection { 1 } }
  no_reflection
}

plane
{
  y, 1.25
  pigment { colour rgbft <0,1,1,0,0> }
  finish { reflection { 1 } }
  no_reflection
}

#local fn_grad=
function {
 pigment {
   gradient x
   color_map { [0 rgb 0][1 rgb 1] }
   sine_wave
   scale 1.2
 }
}

object {
 isosurface {
   function { z-fn_grad(x, y, 0).gray*0.5 }
   max_gradient 0.4
   accuracy 0.001
   contained_by { box { <-1,-2,-1> <1,2,1> } }
   rotate <90,0,180>
   translate z*-1
   scale 0.75
 }
 pigment { colour rgb 1 }
}

#if (1)
plane
{
  z, 1.6
  pigment { colour rgbft <0,0,0,0,0> }
  finish { reflection { 1 } }
  no_reflection
}
#end

//---------------------------------------------------------------------------

If you render it at 320x240, no AA, you will get different results between
3.6 and 3.7. However, if you add

  +sc160 +ec191 +sr76 +er107

to the command-line and render it again you will get identical results - 3.6
will now behave as 3.7 does. To further demonstrate that it's a order issue,
change the #if (1) at the bottom to #if (0) to turn off the reflection behind
the object, and render with the above command-line again. You will see that
the surface renders as expected in both versions.

Hopefully someone with the time will have a look at the existing code in v3.6
and work out what the cause of this is (most likely something very obvious
like a value being stored that depends on the order of calls); for the moment
I have to concentrate on 3.7-specific issues.

thanks for pointing this out,

-- Chris

Post a reply to this message