Port of FS246 - Regression on scale limit between 3.7 and previous releases

[wfpokorny]

http://bugs.povray.org/task/246

(Ported on the chance some change in behavior might be considered, but I think closing OK.

Confirmed behavior remains unchanged as of today. All older POV-Ray source I have on hand has the "Max_Distance" or "MAX_DISTANCE" at 1e7 though evidence in comments suggests it was for a time at 1e10 aligning with Chris's comment it was. Perhaps it being larger for a time is why a previous scene of Thomas's appeared to stop working. I did a test changing the value, now in source/core/configcore.h, to 1e8 and the example (at scale 100*10e4) works.

Also suspect the scale encoding might be part of the tangle here. Thomas stated "I seem to remember that with lower versions of POV-Ray on could go at least to 10e6 which is another way to write 1e7 and 1e7-1e-9 is the last value which has "always worked.")

---

Details:

From Thomas de Groot

Using the following code for a (sky) sphere in a scene, with light source well outside the sphere; works correctly until the above scale value. Use a value of >=100*10e4 and the sphere becomes black

#version 3.7;
global_settings{ assumed_gamma 1.0 }

#declare T_sky =
texture {
  pigment {
    gradient y
    pigment_map {
      [0.0 srgb <1.0,0.7,0.6>*1 transmit 0.5]
      [1.0 srgb <0.8,0.1,0.0>*1 transmit 0.5]
    }
  }
  finish {
    emission 0.9
    diffuse 0.0
  }
}

#declare T_cosmos =
texture {
  pigment {
    color rgbt <0,0,0,1>
  }
  finish {
    ambient 0.0
    diffuse 0.0
  }
}

sphere {
  <0,0,0>,1
  texture {T_sky}
  interior_texture {T_cosmos}
  no_shadow
  no_reflection
  inverse
  scale 99.9*10e4
}

Working with windows version of POV-Ray and Win7 x64

Is this normal for version 3.7 RC5? I seem to remember that with lower versions of POV-Ray on could go at least to 10e6. Especially with the Ringworld scenes back in 2010 the scales used where much larger without any black out.

I can indeed confirm that the Ringworld scene does not render correctly anymore, with identical black out.

---

Comments:

---

Comment by Grimbert Jérôme (Le_Forgeron) - Monday, 25 June 2012, 16:51 GMT+5

Confirmed with Linux 3.7RC6

Seems related to the values in configbackend.h (source/backend/) of SMALL_TOLERANCE & MAX_DISTANCE

---

Comment by Grimbert Jérôme (Le_Forgeron) - Monday, 10 September 2012, 00:38 GMT+5

Additional comment: unable to duplicate the 3.6.1 reported behavior:

With my 3.6.1 (fresh compilation from source), the picture is also full black for a scale of 100.0*10e4

I will check a 3.5 later.

---

Comment by Grimbert Jérôme (Le_Forgeron) - Tuesday, 11 September 2012, 02:12 GMT+5

Well, it's easier to compile 3.1 than 3.5

With 3.1, I got the same behaviour as with 3.6.1 & 3.7RC6 : light red at 99.910e4, full black at 100.010e4

On 3.1, the difference of render between 99.910e4 and 100.010e4 is:

 ----------------------------------------------------------------------------
 Pixels:           10000   Samples:           10000   Smpls/Pxl: 1.00
 Rays:             20000   Saved:                 0   Max Level: 2/5
 ----------------------------------------------------------------------------
 Ray->Shape Intersection          Tests       Succeeded  Percentage
 ----------------------------------------------------------------------------
 Sphere                           20000           13173     65.86
 ----------------------------------------------------------------------------
 Calls to Noise:                  0   Calls to DNoise:             10
 ----------------------------------------------------------------------------
 Transmitted Rays:            10000
 ----------------------------------------------------------------------------
 Smallest Alloc:                 22 bytes   Largest:            12816
 Peak memory used:            67263 bytes
 ----------------------------------------------------------------------------

Versus (100):

----------------------------------------------------------------------------
Pixels:           10000   Samples:           10000   Smpls/Pxl: 1.00
Rays:             10000   Saved:                 0   Max Level: 1/5
----------------------------------------------------------------------------
Ray->Shape Intersection          Tests       Succeeded  Percentage
----------------------------------------------------------------------------
Sphere                           10000           10000    100.00
----------------------------------------------------------------------------
Calls to Noise:                  0   Calls to DNoise:             10
----------------------------------------------------------------------------
----------------------------------------------------------------------------
Smallest Alloc:                 22 bytes   Largest:            12816
Peak memory used:            67263 bytes
----------------------------------------------------------------------------

There is no more transmitted ray for the 100.0*10e4

This is for the Unix code. Maybe the Windows distribution used a bigger MAX_DISTANCE (or Max_Distance, it was spelled differently in previous version; but was still 1.0e7 on Unix since 3.1)

./3.5/povray-3.50c/src/frame.h:#define Max_Distance 1.0e7
./povray-3.7.0.RC5/source/backend/configbackend.h://#define MAX_DISTANCE 1.0e+10 // TODO FIXME #define MAX_DISTANCE 1.0e7
./povray-3.7.0.RC5/source/backend/configbackend.h:#define MAX_DISTANCE 1.0e7
./3.1e/povray31/source/frame.h:#define Max_Distance 1.0e7
./povray-3.6.1/source/frame.h:#define Max_Distance 1.0e7
./povray31/source/frame.h:#define Max_Distance 1.0e7

---

Comment by Chris Cason (chrisc) - Tuesday, 11 September 2012, 03:08 GMT+5

POVWIN hasn't used a different MAX_DISTANCE to that in the main source in any build that I can think of, and a look through the old source and revision history seems to confirm that.

For a while (Feb through May 2005) MAX_DISTANCE was 1.0e+10 and SMALL_TOLERANCE 1.0e-6, but apart from that it's had the old values for as long as I can remember

[c-lipka]

For the records: I consider this a precision issue that we don't want to tackle in a hurry while we prepare for v3.8.0 release.