POV-Ray

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.

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

The following scene shows how photons are “boosted” by pass_through objects; removing one of the boxes will reduce the effect; the effect can be seen with 3.6 as well as current betas:

global_settings {
  max_trace_level 10 // makes a difference!
  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,500,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>
  }
}


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

cylinder {
  <-1.2,0.01,0.8>, <-1.2,2.5,0.8>, 1
  material { M_Glass }
  photons {  // photon block for an object
    target 1.0
    refraction on
    reflection on
  }
}

box {
  <2.4,0,-2.3>, <2.6,4,-0.3>
  material { M_Glass }
  photons { pass_through }
}

box {
  <2.9,0,-2.3>, <3.1,4,-0.3>
  material { M_Glass }
  photons { pass_through }
}

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.

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)

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.

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 configure script for unix uses a dumb string compare to test whether libpng version is 1.2.5 or higher, leading it to reject (for instance) libpng 1.2.27 and unnecessarily compile and statically link the older libpng version it comes with.

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).

In POV-Ray 3.6 (including 3.62), checker and cells patterns are off by 0.001 (1e-3) units, as can be demonstrated with this scene:

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

box { <-1,-1,0>, <0,0,1> pigment { checker color rgb 1 color rgb 0 scale   0.2 translate <-0.5,-0.5,0> } finish { ambient 1 diffuse 0 } }
box { < 1, 1,0>, <0,0,1> pigment { checker color rgb 1 color rgb 0 scale   0.2 translate < 0.5, 0.5,0> } finish { ambient 1 diffuse 0 } }
box { < 1,-1,0>, <0,0,1> pigment { checker color rgb 1 color rgb 0 scale 200.0 translate < 0.5,-0.5,0> } finish { ambient 1 diffuse 0 } }
box { <-1, 1,0>, <0,0,1> pigment { checker color rgb 1 color rgb 0 scale 200.0 translate <-0.5, 0.5,0> } finish { ambient 1 diffuse 0 } }

The same can be demonstrated for the cells pattern.

POV-Ray 3.7 beta 34 is “clean”.

Source code inspection during examination of issues with the scene published at http://povray.sitewww.ch/?p=177 show the following issues with current (beta.34) implementation of dispersion in POV-Ray 3.7:

• The same adjustment to the IOR that is applied at the very first dispersion interface is erroneously applied to all subsequent interfaces.

• As an exception, dispersion adjustment is erroneously not applied to any interface defined by the surface of a non-dispersing object embedded into a dispersing object.

While this still allows to use dispersion for artistic effect, it is neither physically realistic, nor does it match 3.6 behavior.

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 attached TIFF file was created with IC using compression. When used in an image_map, POV-Ray 3.7.0.beta.34 on Windows XP x64 renders the image all transparent, while POV-Ray 3.6.2 renders the file fine. The same effect can be seen with LZW-compressed TIFF files created with Adobe Photoshop 6.0.

Uncompressed TIFF files created with either IC or Photoshop render fine in both versions of POV-Ray.

Stepping through the code of POV-Ray 3.7.0 shows that the same code path is taken regardless of compression, but the libtiff library returns different alpha channel values, indicating a problem in that library. POV-Ray 3.7 still uses libtiff 3.6.1, whereas the POV-Ray 3.6 branch has been updated to libtiff 3.8.2, which according to the change history includes a few alpha-related changes.

Trace level is not handled properly with blobs using per-component reflective or refractive textures, leading to lockups. Stepping through the code, it seems that POV-Ray fails to properly mark the blob object as increasing the trace level.

(Until this bug is fixed, the issue can be worked around in most cases by assigning a reflective texture to the blob as a whole.)

The parser does not accept mesh objects (or CSG objects including a mesh object) as a parameter to the inside() built-in function, reporting error “Solid object identifier expected”, even if the mesh is “solidified” by specifying an inside_vector.

(see news://news.povray.org:119/4a983716@news.povray.org)

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

When rendering a series of scenes (e.g. animation, or render queue in POV-Ray for Windows), number_of_waves is not properly reset to its default value between scenes, causing the parameter to default to the value set by the previous scene.

For instance, rendering the following scenes from a queue will cause “arches.pov” to be rendered differently the second time:

1. scenes\textures\finishes\arches.pov
2. scenes\textures\normals\normavg.pov
3. scenes\textures\finishes\arches.pov (again!)

Bounding box computation for CSG intersection appears to be broken when one member is an arbitrarily transformed plane.

POV-Ray 3.6.2 has the same problem (can’t test for 3.6.1).

// +W640 +H480 +MB1

#include "transforms.inc"

camera {
  location  <-0.2, 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>
}

plane {
  y, -1
  pigment { color rgb <0.7,0.5,0.3> }
}

intersection {
  sphere {
    0.0, 1 }
  plane { -x, 0 transform { Shear_Trans(x,y+x*0.3,z) } }
  texture {
    pigment {
      radial
      frequency 8
      color_map {
        [0.00 color rgb <1.0,0.4,0.2> ]
        [0.33 color rgb <0.2,0.4,1.0> ]
        [0.66 color rgb <0.4,1.0,0.2> ]
        [1.00 color rgb <1.0,0.4,0.2> ]
      }
    }
    finish{
      specular 0.6
    }
  }
  rotate -y*5
}

Some sample scenes are no longer up-to-date, causing warnings, and should be fixed. For instance, the advanced/benchmark scene still includes “Buffer_Output=Off” and “Buffer_Size=0” in its .ini file. This should be checked systematically, and fixed as appropriate.

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

For some particularly “heavy” SDL scripts, it might be desirable to override (or complement) the standard “Parsing 47110815K tokens” progress information with some more helpful custom info, e.g. “Planting trees... (37%)”, or “Generating terrain mesh row 47 of 500”.

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 }

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.

Subsurface scattering must be made radiosity-aware.