POV-Ray

The following (bogus) SDL code causes POV-Ray 3.7 beta to crash hard with an access violation:

#include "fubar.inc"
Bar(42)
#macro FooBar() #end

//fubar.inc
#macro Foo(Fnord) #end
#macro Bar(Ignord) Foo(23 #end

The following scene, showing an almost cylindrical cone floating above a plane, renders fine in POV 3.6.2, but is obviously broken in 3.7.0.beta.34:

camera {
  right     x
  up        y*image_height/image_width
  location  <80,50,40>
  look_at   <0,0,0>
}

light_source { <500,500,500> color rgb 1 }

cone {
  <0,0,30>, 11.303000, <0,0,-30>, 11.302999
  texture { pigment { color rgb 1 } }
}

plane { y, -20 texture { pigment { color rgb 0.3 } } }

The error occurs even with the -MB option, indicating that the problem has nothing to do with bounding, but is in the cone intersection testing code.

The code to attenuate transmitted photons according to surface texture was apparently duplicated during refactoring of the source code for version 3.7. Behavior has changed from 3.6 to 3.7 (beta.36) accordingly, as can be demonstrated with the following scene:

global_settings {
  assumed_gamma 1.0
  max_trace_level 10
  photons { spacing 0.02 }
}

camera {
  right x*image_width/image_height
  location  <0,2.6,-10>
  look_at   <0,0.75,0>
}

light_source {
  <500,300,150>
  color rgb 1.3
  photons {
    refraction on
    reflection on
  }
}

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

plane {
  y, 0
  texture { pigment { color rgb <1.0, 0.8, 0.6> } }
}

#declare M_Glass=
material {
  texture {
    pigment {rgbt 1}
    finish {
      ambient 0.0
      diffuse 0.05
      specular 0.6
      roughness 0.005
      reflection { 0.1, 1.0 fresnel on }
      conserve_energy
    }
  }
  interior {
    ior 1.5
    fade_power 1001
    fade_distance 0.9
    fade_color <0.5,0.8,0.6>
  }
}

#declare M_PseudoGlass2=
material {
  texture {
    pigment {rgbf <0.8,0.2,0.2,0.8>}
    finish {
      ambient 0.0
      diffuse 0.05
      specular 0.6
      roughness 0.005
      reflection { 0.1, 1.0 fresnel on }
      conserve_energy
    }
  }
  interior {
    ior 1.0
  }
}

sphere {
  <1.1,1,-1.3>, 1
  material { M_Glass }
  photons {
    target 1.0
    refraction on
    reflection on
  }
}

box {
  <2.4,0,-2.3>, <2.6,4,0.3>
  material { M_PseudoGlass2 }
  photons { target 1.0 refraction on reflection on }
}

In the following scene, the mesh object will always cast a fully-opaque shadow, even if the image has an alpha channel:

camera {
  location  <0.5, 1.0, -1.0>
  look_at   <0.5, 0.0,  0.5>
}

light_source { <0, 30, 0> color rgb 1 }

mesh {
    triangle { <0,0,0>, <1,0,0>, <1,0,1> uv_vectors <0,0>, <1,0>, <1,1> }
    triangle { <0,0,0>, <1,0,1>, <0,0,1> uv_vectors <0,0>, <1,1>, <0,1> }
    texture { pigment { uv_mapping image_map {png "FOOBAR.png"} } }
}

plane { y, -0.1 pigment { color rgb 1 } }

The following modification to the texture will give the expected results:

    texture { uv_mapping pigment { image_map {png "FOOBAR.png"} } }

The problem can be observed with both POV-Ray 3.7 (tested with beta.34), as well as 3.6 (tested with 3.6.2).

File output code for virtually all file formats performs gamma correction on unclipped color values, which leads to issues when color values happen to be negative for some reason and gamma does not happen to be an integer value such as 1.0 or 2.0. As a consequence, subsequent steps (clipping and converting to integer) apparently produce compiler-dependent results. Compiled with Microsift or Intel compilers, POV-Ray seems to write zero brightness in such cases, while compiled with g++ 4.4 (and possibly other compilers) it seems to write full brightness instead.

(See thread news://news.povray.org:119/4ba819f6@news.povray.org for examples.)

The proper solution should be to apply gamma correction after clipping.

When choosing PPM output with a bit depth other than 8 bits per color channel (e.g. +FP16), POV-Ray messes up the colors (see thread news://news.povray.org:119/4babb48f$1@news.povray.org)

In pvengine.cpp (file revision 154), lines 4003-4006 are exact duplicates of lines 3999-4002:

3997    case KEYWORD_LOOKUP_MESSAGE :
3998         hh_aklink.pszKeywords = (LPCSTR) lParam ;

3999         if (strncmp (hh_aklink.pszKeywords, "oooo", 4) == 0)
4000           hh_aklink.pszKeywords = ""  ;
4001         if (strncmp (hh_aklink.pszKeywords, "//", 2) == 0)
4002           hh_aklink.pszKeywords = ""  ;

4003         if (strncmp (hh_aklink.pszKeywords, "oooo", 4) == 0)
4004           hh_aklink.pszKeywords = ""  ;
4005         if (strncmp (hh_aklink.pszKeywords, "//", 2) == 0)
4006           hh_aklink.pszKeywords = ""  ;

4007         HtmlHelp (NULL, engineHelpPath, HH_KEYWORD_LOOKUP, (DWORD_PTR) &hh_aklink) ;
4008         return (true) ;

This duplication appears pretty much useless to me - or am I missing something?

The following code is erroneously accepted by POV-Ray (tested with 3.7.0.beta.36):

pigment{
  slope { x }
  checker
}

The result is a checker pattern.

Apparently there is an EXIT statement missing in the slope-pattern parsing code in parstxtr.cpp.

Setting File_Gamma=1.0 produces unexpectedly bright output files for most output file formats, as if File_Gamma was set to 2.2 instead.

The underlying problem is a bug that, when File_Gamma is set to exactly 1.0, causes the encoding gamma function to be undefined, which was not meant to happen in current versions, and instead was reserved for future versions to signal that a file-format-specific default encoding gamma should be used. The image file output handlers already support this, most of them choosing the sRGB transfer function, giving roughly the same output as setting File_Gamma=2.2.

As a preliminary workaround, users may want to set File_Gamma=1.02 (any value smaller than 0.99 or greater than 1.01 should do).

Reflections in multi-layered textures are broken in 3.7 betas, as can be demonstrated with the following scene showing two reflective hemispheres on a checkered plane:

camera {
  location  <1.0, 0.5, -4.0>
  direction 1.5*z
  right     x*image_width/image_height
  look_at   <0.0, 0.0,  0.0>
}

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

light_source {
  <0, 0, 0>            // light's position (translated below)
  color rgb <1, 1, 1>  // light's color
  translate <-30, 30, -30>
}

default {
 finish { diffuse 0 ambient 0 specular 0 }
}

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

plane {               // checkered floor
  y, -1
  texture
  {
    pigment { checker color rgb 1 color blue 1 }
    finish{ diffuse 0.8 ambient 0.1 }
  }
}

// left hemisphere
intersection {
  sphere { 0, 1 }
  plane { x, -0.002 }
  texture {
    pigment { color rgb 1 }
    finish{ reflection { 0.5 } }
  }
  texture {
    pigment { color rgbt 1 }
    finish{ reflection { 0.4 } }
  }
  texture {
    pigment { color rgbt 1 }
    finish{ reflection { 0.1 } }
  }
}

// right hemisphere
intersection {
  sphere { 0, 1 }
  plane { -x, -0.002 }
  texture {
    pigment { color rgb 1 }
    finish{ reflection { 1.0 } }
  }
}

Note that the reflection parameters of the left, multi-layered hemisphere sum up to 1.0, i.e. the same value as used in the single layer in the right hemisphere.

The first attached file (test_3.6.2.png), rendered with POV-Ray 3.6.2, shows the expected output: Both hemispheres appear to have the same reflectivity.

The second attached file (test_3.7.0.beta37a.png), rendered with POV-Ray 3.7.0.beta.37a, shows a much brighter left (multi-layered) sphere.

As it turns out, in order to get the expected result with POV-Ray 3.7.0.beta.37a, the reflectivity of each layer must be divided by 3, 2 and 1, respectively (which obviously does not sum up to 1.0):

  ...
  texture {
    pigment { color rgb 1 }
    finish{ reflection { 0.5 / 3 } }
  }
  texture {
    pigment { color rgbt 1 }
    finish{ reflection { 0.4 / 2 } }
  }
  texture {
    pigment { color rgbt 1 }
    finish{ reflection { 0.1 / 1 } }
  }
  ...

The current Windows version of POV-Ray does not fully support forward slashes in pathnames; specifically, POV-Ray fails to recognize drive letters when followed by a forward slash, e.g. “C:/foo/bar.pov” or “C:/foo\bar.pov”, rejecting such names for e.g. Input_File_Name.

POV-Ray 3.7-generated JPEG image output files do not conform to the JFIF standard. Most importantly, the files written do not use the standard YCbCr color model (they seem to use plain RGB instead), nor do they have a proper JFIF tag.

As a consequence, some software may be unable to read the generated JPEG files properly. In addition, it seems that POV-Ray mixes up the Red and Blue channels.

Automatic removal of user-specified bounding boxes cannot be disabled in current POV-Ray 3.7 betas; the Remove_Bounds ini file setting and the +/-UR command line option are silently ignored.

OpenEXR output currently writes an alpha channel when Output_Alpha=off (-UA), and does not write an alpha channel when Output_Alpha=on (+UA), i.e. doing it just the wrong way round.

When using “filter all VALUE” with an image_map using a 4-bit (16-color) paletted bmp image, debug builds of POV-Ray fail with an assertion.

According to code analysis, other paletted image formats with <256 palette entries are also likely to be affected; similar assertion fails can be expected when using the “filter INDEX, VALUE” feature on such files with an index exceeding the palette size. “transmit” shows the same flaws.

Input image files may have been created with gamma pre-correction for some specific target gamma, which may vary from image to image. Some file formats like PNG or HDR support embedding gamma pre-correction information in the image file, but this information may be missing or faulty, and some formats don’t support it at all. Additionally, it may be desirable to tamper with an input image’s gamma for artistic reasons.

Therefore, I suggest adding a means to explicitly specify input images’ originally intended target gamma on a per-image basis, like:

image_map { jpeg "MyImage.jpg" assumed_gamma 1.8 }

Multi-textured blobs are broken with 3.7 beta 40 when used inside an intersection, as can be demonstrated by the following scene:

#default { texture { pigment { rgb 1 } } }

camera {
  right x*image_width/image_height
  location  <0,1.5,-4>
  look_at   <0,1,0>
}

light_source { <500,500,-500> color rgb 1 }

difference { blob {
  threshold 0.6
  sphere { < 0.75,   0,    0>, 1, 1 texture { pigment { color red 1 } } }
  sphere { <-0.375,  0.65, 0>, 1, 1 texture { pigment { color green 1 } } }
  sphere { <-0.375, -0.65, 0>, 1, 1 }
} }

With POV-Ray 3.7.0 beta 40, the entire blob is rendered with the default texture.

The same problem can be seen with “difference” or “merge” instead of “intersection”.

Omitting the CSG “envelope”, using “union”, or assigning the blob to a variable first and then using it inside an intersection, will yield the expected result.

POV-Ray 3.62 renders all variants as expected.

According to initial analysis, the problem appears to be caused by the dual use of the “MULTITEXTURE_FLAG”, which is used in CSG to indicate use of the “cutaway_textures” feature, and in blobs to indicate per-element texturing. (The same flag is also used in meshes to indicate per-face or per-vertex texturing, so similar problems are to expected there.)

My proposal is to use an entirely separate flag for the “cutaway_textures” feature (the blob and mesh can safely continue to share the MULTITEXTURE_FLAG).

If pretrace_start is set below pretrace_end, POV-Ray will run a high number of pretrace steps (without changing pretrace resolution).

polygon objects comprised of multiple “sub-polygons” don’t work properly if start/end points of sub-polygons do not exactly match, as can be demonstrated by the following code:

#default { texture { pigment { rgb 1 } finish { ambient 1.0} } }

camera {
  orthographic
  up 3.5*y
  right 3.5*x*image_width/image_height
  location  <0,0,-4>
  look_at   <0,0,0>
}

polygon { 8,
  // outer triangle
  0.70 * < cos(  0 *pi/180),sin(  0 *pi/180),0>
  0.70 * < cos(120 *pi/180),sin(120 *pi/180),0>
  0.70 * < cos(240 *pi/180),sin(240 *pi/180),0>
  0.70 * < cos(360 *pi/180),sin(360 *pi/180),0>

  // inner triangle
  0.35 * < cos(  0 *pi/180),sin(  0 *pi/180),0>
  0.35 * < cos(120 *pi/180),sin(120 *pi/180),0>
  0.35 * < cos(240 *pi/180),sin(240 *pi/180),0>
  0.35 * < cos(360 *pi/180),sin(360 *pi/180),0>
}

Note that the end points /should/ be identical. There are however some minor rounding differences, which mess up polygon computations. Compare with the following code, which leads to the desired results:

polygon { 8,
  // outer triangle
  0.70 * < cos(  0 *pi/180),sin(  0 *pi/180),0>
  0.70 * < cos(120 *pi/180),sin(120 *pi/180),0>
  0.70 * < cos(240 *pi/180),sin(240 *pi/180),0>
  0.70 * < cos(  0 *pi/180),sin(  0 *pi/180),0>

  // inner triangle
  0.35 * < cos(  0 *pi/180),sin(  0 *pi/180),0>
  0.35 * < cos(120 *pi/180),sin(120 *pi/180),0>
  0.35 * < cos(240 *pi/180),sin(240 *pi/180),0>
  0.35 * < cos(  0 *pi/180),sin(  0 *pi/180),0>
}

Code inspection shows that the polygon insideness testing code tests for precise equality of the points, whereas the general policy of POV-Ray is to accept slight rounding differences.

‘povray -H10 -W20 myscene.pov’ will generate a file with a picture 10 pixels high and 20 pixels wide, BUT in the message pane it displays

Image resolution.....20 by 10 (rows 1 to 20, columns 1 to 10)

instead of

Image resolution.....20 by 10 (rows 1 to 10, columns 1 to 20)

or

Image resolution.....20 by 10 (columns 1 to 20, rows 1 to 10) 

UV-mapped textures for parametrics are broken in POV-Ray 3.70 RC3, in cases where two (or more) parametrics overlap in a scene.

In the following scene, note how the texture per se is always taken properly from whichever parametric is in front, while the UV coordinates are erroneously taken always from the red parametric where both overlap, no matter whether it is in front or back.

camera {
  location  <0.0, 1.5, -3.0>
  direction 1.5*z
  right     x*image_width/image_height
  look_at   0
}

light_source { <-30, 30, -30> color rgb 1 }

#declare Param = parametric {
  function { u*v*sin (15*v) },
  function { v },
  function { u*v*cos (15*v) }
  0, 1
  contained_by { box { -1,1 } }
  accuracy 0.002
  precompute 15 x,y,z
  rotate 180*x
  translate  <0.3,0.5,0>
}

object {
  Param
  uv_mapping
  texture {
    pigment {
      gradient x frequency 3
      color_map {
        [0 color red .5 ]
        [1 color red 1 ]
      }
    }
  }
}

object {
  Param
  uv_mapping
  texture {
    pigment {
      gradient x frequency 7
      color_map {
        [0 color green .5 ]
        [1 color green 1 ]
      }
    }
  }
  rotate y*180
}

POV-Ray 3.62 renders the scene properly.

As this bug has been found during code inspection, the uderlying cause has already been identified; I’m currently working on a fix.

Adjusting the brightness of an image-mapped sky sphere, although not an uncommon task especially when using HDR light probes, currently is cumbersome at best, as it is not possible to specify a “finish { ambient ... }” statement.

To simplify tuning a sky sphere’s brightness, I suggest introducing a “brightness FLOAT” modifier (defaulting to 1.0) to either the sky_sphere block or (as a more versatile solution) the image_map statement.

original post on povray.beta-test:

POV-Ray 3.7.0.RC3 on Slackware 13.0 x86_64.
I pointed povray to use the calibri.ttf font over on my Windows 7 partition.
The result is garbled - strange letters with accents appear instead of the
expected text. (KDE's kfontview opens calibri.ttf OK, with nothing strange).

Pointing povray to use other fonts of Win7, e.g. comic.ttf and arial.ttf, was
OK.

I solved the problem by pushing calibri.ttf through fontforge and resaving it
as mycalibri.ttf.

Cheers,
Peter

Confirmed with development version on Windows XP x64.

Possibly a similar problem as  FS#162 .

original posting from povray.beta-test:

I get this error message:
"Parse Error: bad allocation  Render failed"
- after the code below has been running for about 3 seconds.

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7

#version 3.7;

#while (true)
  #local Fn = function { transform { translate <0, 0, 0> } }
  #undef Fn
#end // while

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7

I'm using POV-Ray for Windows - Version 3.7.0.RC3.msvc9-sse2.win32
The operating system is Windows XP.

With the code above, the error messages has so far appeared every time
right after 3318K tokens have been parsed. But with other versions of
my code, the error message does not always show up. (Sometimes the
render finishes and sometimes the parsing stops at different "times".)

[...]

Other users report no error message, but memory consumption rising to about 1.2 GB.

According to the docs, the panoramic camera...

[...] uses a type of cylindrical projection to be able to use viewing angles larger than 180 degrees with a tolerable lateral-stretching distortion. The angle keyword is used to determine the viewing angle.

However, current implementation differs (and probably always has): The angle keyword has no effect, and the effective viewing angle is fixed to 180 degrees. Also note that this behaviour is identical to the spherical camera with angle 180,180, making the panoramic camera obsolete.

I propose to deprecate the “panoramic” keyword; should the keyword be encountered in a camera block, the code for the spherical camera should be used instead, except that the angle setting should be forced to 180,180; this should be accompanied by a parse warning.

The following SDL code causes a hard crash during parsing if _3024_dot_dat is undefined:

light_source {
    <0, 0, 0>
    color rgb 0.5*<1,0.905882,0.211765>
    fade_distance 500
    fade_power 1.6
    looks_like {_3024_dot_dat texture {
        pigment { rgbf <1,0.905882,0.211765,0.90> }
        finish { ambient 0.6 diffuse 0 phong 0.5 phong_size 40
            reflection 0.9
            refraction 1 ior 1.25
            }
        }
}    } 

The following scene reders differently with POV-Ray 3.7.0.RC3 than with POV-Ray 3.6.2:

camera
{
    right x*image_width/image_height
    location  <0, 0, -5>
    look_at   <0, 0, 0>
}

light_source
{
    <0,0,0>
    color rgb 1
    looks_like
    {
        box {
            <-1,-1,-0.1>, <1,1,0.1>
            pigment { wood }
            finish { ambient 5.0 diffuse 0 specular 0 phong 0 reflection 0 }
            scale 0.5
        }
    }
    translate <1,0,0>
}

plane
{
    <0, 1, 0>, -1
    texture
    {
        pigment { color rgb <0.5, 0.5, 0.55> }
        finish { specular 1.0 }
    }
}

See attachments for the output. As can be seen, POV-Ray 3.7 does translate the shape of the looks_like object along with the light source, but fails to translate the textures.

Consider the following script:

  #fopen F "foo.txt" read
  #read (F, Foo)
  #debug concat ("'", Foo, "'\n")
  #fclose F

Now assume that foo.txt erroneously contains unquoted text (which will result in a parse error):

  Blah

When the error is reported, POV-Ray for Windows will helpfully open foo.txt, but any attempt to save a corrected version of foo.txt will fail until you exit the POV-Ray GUI, presumably because foo.txt is not properly closed by the parser.

POV-Ray fails to accept UTF-8 encoded files with a leading Byte Order Mark.

According to the code it was intended to recognize a leading BOM (or, more precisely, leading non-ASCII code sequences) and automatically switch to UTF-8, so this must be considered a bug rather than a missing feature.

Quoted strings as parameters to command-line options work on the command line but not in INI files; e.g.:

+i"test.pov"

Root cause has already been identified (actually the problem was found during code inspection) and a fix is under way.

Subsurface scattering must be made radiosity-aware.

As the following scene demonstrates, the “inverse” keyword produces unexpected results with quadrics.

Left: a sphere primitive as reference
Right: a sphere-shaped quadric primitive (sphere-shaped)

Top: plain
Bottom: inverse

The objects are clipped in half to better demonstrate the effect. Regular texture is shown in white, interior_texture in red; the surface normal of a selected point (blue) as returned by trace() is shown in green.

Note how the sphere’s surface normal, as well as the textures, are flipped when “inverse” is used (this is the intended standard behaviour of all objects), while the quadric’s normal and textures erroneously remain uchanged.

// +w800 +h600

#version 3.7;

global_settings{ assumed_gamma 1.0 }

#default{ finish { ambient 0.1 diffuse 0.9 specular 0.5 }} 

camera {
  perspective
  angle 40
  right     x*image_width/image_height
  location  <0,0,-10>
  look_at   <0,0,0>
}

light_source{ < 1000,3000,-3000> color rgb 1 }

background { color rgb 0.5 }

#declare T_White = texture { pigment { color rgb   1 } }
#declare T_Red   = texture { pigment { color red   1 } }
#declare T_Green = texture { pigment { color green 1 } }
#declare T_Blue  = texture { pigment { color blue  1 } }

#declare TopLeft     = sphere { 0, 1 }
#declare BottomLeft  = sphere { 0, 1 inverse }

#declare TopRight    = quadric { <1,1,1>, <0,0,0>, <0,0,0>, -1 }
#declare BottomRight = quadric { <1,1,1>, <0,0,0>, <0,0,0>, -1 inverse }

#macro Mac(Obj, P, D)
  union {
    #local N = <0,0,0>;
    #local O = <-0.6,0.4,-10>;
    #local Q = trace(Obj, O, D, N);
    #if (vlength(N) > 0)
      sphere { Q, 0.05 texture { T_Blue } }
      cylinder { Q, Q + N, 0.02 texture { T_Green } }
    #else
      cylinder { O, O + D*10000, 0.02 texture { T_Red } }
    #end
    object { Obj texture { T_White } interior_texture { T_Red } clipped_by { box { <-1,-1,-1>, <0,1,1> rotate y*30 } } }
    translate P
  }
#end

Mac(TopLeft,     <-1.2, 1.2, 0>, z)
Mac(TopRight,    < 1.2, 1.2, 0>, z)
Mac(BottomLeft,  <-1.2,-1.2, 0>, z)
Mac(BottomRight, < 1.2,-1.2, 0>, z)

As the following scene demonstrates, the “inverse” keyword produces unexpected results with fractals.

Left: a sphere primitive as reference
Right: a julia fractal

Top: plain
Bottom: inverse

The objects are clipped in half to better demonstrate the effect. Regular texture is shown in white, interior_texture in red; the surface normal of a selected point (blue) as returned by trace() is shown in green.

Note how the sphere’s surface normal, as well as the textures, are flipped when “inverse” is used (this is the intended standard behaviour of all objects), while the fractal’s normal and textures erroneously remain uchanged.

// +w800 +h600

#version 3.7;

global_settings{ assumed_gamma 1.0 }

#default{ finish { ambient 0.1 diffuse 0.9 specular 0.5 }} 

camera {
  perspective
  angle 40
  right     x*image_width/image_height
  location  <0,0,-10>
  look_at   <0,0,0>
}

light_source{ < 1000,3000,-3000> color rgb 1 }

background { color rgb 0.5 }

#declare T_White = texture { pigment { color rgb   1 } }
#declare T_Red   = texture { pigment { color red   1 } }
#declare T_Green = texture { pigment { color green 1 } }
#declare T_Blue  = texture { pigment { color blue  1 } }

#declare TopLeft     = sphere { 0, 1 }
#declare BottomLeft  = object { TopLeft inverse }

#declare TopRight    = julia_fractal{ <-0.083,0.0,-0.83,-0.025> quaternion sqr max_iteration 8 precision 20 scale 0.9 }
#declare BottomRight = object { TopRight inverse }

#macro Mac(Obj, P, D)
  union {
    #local N = <0,0,0>;
    #local O = <-0.6,0.4,-10>;
    #local Q = trace(Obj, O, D, N);
    #if (vlength(N) > 0)
      sphere { Q, 0.05 texture { T_Blue } }
      cylinder { Q, Q + N, 0.02 texture { T_Green } }
    #else
      cylinder { O, O + D*10000, 0.02 texture { T_Red } }
    #end
    object { Obj texture { T_White } interior_texture { T_Red } clipped_by { box { <-2,-2,-2>, <0,2,2> rotate y*30 } } }
    translate P
  }
#end

Mac(TopLeft,     <-1.2, 1.2, 0>, z)
Mac(TopRight,    < 1.2, 1.2, 0>, z)
Mac(BottomLeft,  <-1.2,-1.2, 0>, z)
Mac(BottomRight, < 1.2,-1.2, 0>, z)

The following scene demonstrates how media sampling method 3 gives inaccurate results with scattering media.

The scene shows four spheres with uniform media, using (left to right) sampling methods 1, 2 and 3 with default settings, and sampling method 3 with high minimum sample count, respectively.

Note how changing the sample count significantly affects the result, despite the media being uniform.

Code analysis shows that the root cause is an underestimation of the extinction effect on the light scattered by the media, corresponding in order of magnitude to half the distance between mandatory samples (as defined by minimum sample count).

The effect also leads to visible artifacts when nesting hollow objects inside the media, as can be demonstrated by un-commenting the four smaller spheres.

#version 3.7;

camera {
  perspective angle 25
  location  <0.0 , 0.0 ,-20.0>
  right     x*image_width/image_height
  look_at   <0.0 , 0.0 , 0.0>
}

light_source {
  <0,3000,-3000> color rgb 1
}

background { color rgb 0.5 }

plane {
  <0,1,0>, -1
  texture { pigment { checker color rgb<1,1,1>*1.2 color rgb<0.25,0.15,0.1>*0 } }
}

#declare T_Transparent = texture {
  pigment { color rgbt <1,1,1,1> } finish { diffuse 1 }
}

sphere { <-3,0,0>, 1.00 
  texture { T_Transparent }
  hollow
  interior {
    media {
      scattering { 1 color rgb 2 extinction 1 }
      method 1
    }
  }
}

sphere { <-1,0,0>, 1.00 
  texture { T_Transparent }
  hollow
  interior {
    media {
      scattering { 1 color rgb 2 extinction 1 }
      method 2
    }
  }
}

sphere { <1,0,0>, 1.00 
  texture { T_Transparent }
  hollow
  interior {
    media {
      scattering { 1 color rgb 2 extinction 1 }
      method 3
    }
  }
}

sphere { <3,0,0>, 1.00 
  texture { T_Transparent }
  hollow
  interior {
    media {
      scattering { 1 color rgb 2 extinction 1 }
      method 3
      samples 100
    }
  }
}

/*
sphere { <-3,0,0>,0.8 texture { T_Transparent } hollow }
sphere { <-1,0,0>,0.8 texture { T_Transparent } hollow }
sphere { < 1,0,0>,0.8 texture { T_Transparent } hollow }
sphere { < 3,0,0>,0.8 texture { T_Transparent } hollow }
*/

The following files were garbled in changelist #4648 by stripping all line terminators, making the files unusable:

• .../scenes/advanced/cats/cattext.inc
• .../scenes/animations/life/blink4.inc
• .../scenes/animations/life/walker.inc

Line terminators of these files were already problematic in previous versions of the file, having been CR-only.

The following files changed with #4648 should be reviewed closely as well, as they were previously CR-only, too, and at least some of them exhibit some peculiarities regarding line and/or file terminators:

• .../scenes/animations/pentmap/pentmap.ini
• .../scenes/animations/pentmap/pentmap.pov
• .../scenes/animations/slinky/slnk.ini
• .../scenes/incdemo/metals/metals.doc
• .../scenes/incdemo/stones/stones.doc
• .../scenes/incdemo/woods/morewood.doc
• .../scenes/incdemo/woods/woods.doc
• .../scenes/textures/pigments/skies/skies.doc