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 following scene has four spheres with different pigment color & filter settings:

- Left: filter 1
- Right: filter 0

- Top: red 0.0 green 0.5 blue 1.0
- Bottom: red 0.00 green 0.05 blue 0.10 (10% of the above)

Background is set to black, so that we only see the diffuse component of the object’s effective color.

Theoretically, both left spheres should be invisible, as they are fully transmissive (with a filtering effect), but apparently with a high filter setting, reducing an object’s pigment color actually increases the object’s effective diffuse color.

//+w600 +h600

global_settings{ assumed_gamma 1.0 }

camera {
  orthographic
  location  <0,0,-10>
  right 4*x
  up 4*y
  look_at   <0,0,0>
}

light_source{<10,10,-10> color rgb 1 parallel }

background { color rgb 0 }

default {
  finish {
    ambient 0
    diffuse 1
    specular 0
    phong 0
    reflection { 0.0 }
  }
}


sphere { <-1, 1, 0>, 0.8 texture { pigment { color rgb <0,0.5,1.0> filter 1.0 } } }
sphere { < 1, 1, 0>, 0.8 texture { pigment { color rgb <0,0.5,1.0> filter 0.0 } } }

sphere { <-1,-1, 0>, 0.8 texture { pigment { color rgb <0,0.5,1.0>*0.1 filter 1.0 } } }
sphere { < 1,-1, 0>, 0.8 texture { pigment { color rgb <0,0.5,1.0>*0.1 filter 0.0 } } }

This bug has been around in 3.6 already.

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.

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.

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.

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

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

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

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
}

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.

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.

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

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.

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 .

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.

Thin tori exhibit artifacts in 3.7.0 RC3 when the camera is placed inside the torus close to its “center plane”, as can be demonstrated with the following scene:

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

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

torus {
  1, 0.001
  texture { pigment { color red 1 } }
}

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

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.

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 }

Using an end value of 1048576 or larger in a #for loop will cause the last iteration to be skipped, as can be demonstrated by the following code:

#declare N = 2000000;
#debug concat(”N = “,str(N, 0,50),”\n”)
#debug concat(”N-5 = “,str(N-5,0,50),”\n\n”)
#for (I, N-5, N, 1)

#debug concat("I   = ",str(I,0,50),"\n")

#end

(The limit was observed with a Win64 build; other builds may exhibit other limits or might even work fine, depending on the floating point engine used.)

As this limit is still far below the numeric precision limit, and a corresponding #while loop works fine with much higher values, this must be considered a bug rather than an inevitable limitation.

The bug can be tracked down to a faulty condition in tokenize.cpp, Parser::Parse_Directive(), CASE(END_TOKEN), case FOR_COND:

    if ( ((Step > 0) && (*CurrentPtr >= End + EPSILON)) ||
         ((Step < 0) && (*CurrentPtr <= End - EPSILON)) )

which should instead be:

    if ( ((Step > 0) && (*CurrentPtr > End + EPSILON)) ||
         ((Step < 0) && (*CurrentPtr < End - EPSILON)) )

A pigment statement not wrapped in a texture statement does not properly override a pigment previously defined for the object. In the following SDL code:

  #declare PLANE = plane { y,0
    texture {
      pigment { checker color rgb 1 color rgb 0 scale 0.1 }
  } }
  object { PLANE
    pigment { checker color red 1 color blue 1 scale 1.0 }
  }

the scaling of the pigment previously specified for the PLANE object is retained for the new pigment. Compare:

  #declare PLANE = plane { y,0
    texture {
      pigment { checker color rgb 1 color rgb 0 scale 0.1 }
  } }
  object { PLANE
    texture {
      pigment { checker color red 1 color blue 1 scale 1.0 }
  } }

which behaves as expected.

The issue has been around at least since POV-Ray 3.6.2.

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