POV-Ray

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

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

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.

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)

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.

POV-Ray 3.7 does not show output options, such as:

Output Options
  Image resolution 640 by 480 (rows 1 to 480, columns 1 to 640).
  Output file: D:\foo\test.png, 24 bpp PNG
  Graphic display......On  (gamma: 2.2)
  Mosaic preview.......Off
  CPU usage histogram..Off
  Continued trace......Off

(the above is what 3.6 used to show)

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.

Currently, output image is buffered using POV-Ray’s RGBFT color model and floating point values, leading to a memory consumption of 20 bit per pixel. This is an unproportionally large memory footprint, given that the only further processing performed on the buffered data is conversion of the data to the desired output file format, which will typically use only 3 bytes per pixel (at most 12 bit per pixel).

The situation can be improved by choosing the output image buffer container based on the desired output file format and parameters. To this end, the following code changes should be made:

• Bundle image file format handler code into classes (typically one per file format)
• Include a method to determine the best data container type for the image buffer
• Instantiate the desired image file format handler object prior to rendering, querying the handler object for an image buffer

In addition to picking a suitable image data container from the already existing palette, careful design might also allow to use custom containers to directly pass the data to a library (in case the library provides its own buffering anyway), or write it directly to the output file (e.g. when writing image data to stdout). To make this compatible with multithreaded rendering, the following changes would have to be made:

• Add code to detect when a row of SMP blocks has been finished, and call a certain method on the image handler object
• Design the custom containers in such a way that they can buffer any number of unfinished SMP block rows as needed

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
}

In some cases it may be desirable to run POV-Ray from a batch file, without causing it to “steal the focus”.

I suggest making this dependant on whether POV-Ray is run with the /EXIT parameter.

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.

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

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

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.

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.

When running make on Linux, the backend source files (and possibly others?) are apparently compiled twice: first from the .../source/backend/ directory, and another time from the .../source/ directory. As an example, here are the corresponding lines for sphsweep.cpp:

g++ -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../../source -I../../source -I../../source/base -I../../unix -I../../vfe 
-I../../vfe/unix -pthread -I/usr/include/OpenEXR    -pthread -I/usr/include  -pipe -Wno-multichar -Wno-write-strin
gs -fno-enforce-eh-specs -s -O3 -ffast-math -pthread -MT sphsweep.o -MD -MP -MF .deps/sphsweep.Tpo -c -o sphsweep.
o `test -f 'shape/sphsweep.cpp' || echo './'`shape/sphsweep.cpp

g++ -DHAVE_CONFIG_H -I. -I..  -I.. -I../source/backend -I../source/base -I../source/frontend -I../unix -I../vfe -I.
./vfe/unix -pthread -I/usr/include/OpenEXR    -pthread -I/usr/include  -pipe -Wno-multichar -Wno-write-strings -fno
-enforce-eh-specs -s -O3 -ffast-math -pthread -MT sphsweep.o -MD -MP -MF .deps/sphsweep.Tpo -c -o sphsweep.o `test 
-f 'backend/shape/sphsweep.cpp' || echo './'`backend/shape/sphsweep.cpp

This is especially annoying on platforms that are rather slow at compiling.

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.

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

When using fade_distance and fade_power in combination with area_illumination, the light source fading is not applied to materials with subsurface scattering; see the following code for an example:

#version 3.7;
global_settings {
  assumed_gamma 1.0
  mm_per_unit 10
  subsurface { samples 200,20 }
}

camera {
  right x*image_width/image_height
  angle 30
  location  <0,1.5,-4>
  look_at   <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>]
    }
  }
}

plane {
  y, 0
  texture {
    pigment {
      checker
      color rgb <1.0, 0.8, 0.6>
      color rgb <1.0, 0.0, 0.0>
      scale 0.5
    }
  }
}

light_source {
  <50,50,50>
  color rgb 30
  area_light 5*x,5*y,17,17 adaptive 1 jitter circular orient
  area_illumination on
  fade_distance 10
  fade_power 2
}

cylinder {
  <0,0,0>, <0,0.2,0> 1
  texture {
    pigment { color rgb 1 }
    finish {
      ambient 0
      diffuse 0.7
      specular albedo 0.3
      reflection { 0.3 fresnel }
      conserve_energy
      subsurface { translucency 0.1 }
    }
  }
  interior { ior 1.5 }
}

sphere {
  <0,0.4,0>, 0.2
  texture {
    pigment { color rgb <1,0.6,0.0> }
    finish {
      ambient 0
      diffuse 0.0
      specular albedo 0.8 metallic
      reflection { 1.0 metallic }
      conserve_energy
    }
  }
}

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

Blobs are currently limited to 1,000,000 components (with each cylindrical component counting as three: one cylinder + two end hemispheres); this limit may have served a historic purpose, but is now entirely arbitrary: The remaining code is limited only by the available RAM and the numeric limits of the int data type. The arbitrary maximum components limit per blob should therefore be removed.

Aside from unnecessarily limiting the power of the blob component, another drawback of the current test is that it is only performed after parsing of all the blob’s components, potentially hours after the limit had actually been reached.

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

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

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.

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