POV-Ray

Originally resolved in https://bugs.gentoo.org/show_bug.cgi?id=425450.
Attached is a patch with Gentoo-specific code removed.

There are two parts in this issue:

• The newer boost library requires downstream users to explicitly link to the boost system library (-lboost_system).
• The newer boost library replaced TIME_UTC with TIME_UTC_, because glibc added TIME_UTC.

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.

Compiling the sources with clang instead of g++ (on ubuntu 12.10 with boost 1.50)

./configure COMPILED_BY=”your name here <also@email>” LIBS=-lboost_system –disable-io-restrictions CC=clang CXX=clang

there is a few warnings that catch the eyes (and other as well that I dismiss so far, such as cases not covered in switch and empty body in if, or extraneous parentheses in tests):

support/randomsequences.cpp:553:15: warning: field is uninitialized when used here [-Wuninitialized]
                        startIndex(startIndex)
                                   ^
support/randomsequences.cpp:553:15: warning: field is uninitialized when used here [-Wuninitialized]
support/randomsequences.cpp:974:40: note: in instantiation of member function 'pov::PrecomputedNumberGenerator<int>::PrecomputedNumberGenerator' requested here
        SeedableIntGeneratorPtr generator(new PrecomputedIntGenerator(factory, count));
                                              ^
support/randomsequences.cpp:553:15: warning: field is uninitialized when used here [-Wuninitialized]
                        startIndex(startIndex)
                                   ^
support/randomsequences.cpp:984:43: note: in instantiation of member function 'pov::PrecomputedNumberGenerator<double>::PrecomputedNumberGenerator' requested here
        SeedableDoubleGeneratorPtr generator(new PrecomputedDoubleGenerator(factory, count));
                                                 ^
support/randomsequences.cpp:553:15: warning: field is uninitialized when used here [-Wuninitialized]
                        startIndex(startIndex)
                                   ^
support/randomsequences.cpp:1011:43: note: in instantiation of member function 'pov::PrecomputedNumberGenerator<pov::Vector3d>::PrecomputedNumberGenerator' requested here
                return SequentialVectorGeneratorPtr(new PrecomputedVectorGenerator(factory, count));
                                                        ^
support/randomsequences.cpp:553:15: warning: field is uninitialized when used here [-Wuninitialized]
                        startIndex(startIndex)
                                   ^
support/randomsequences.cpp:1056:45: note: in instantiation of member function 'pov::PrecomputedNumberGenerator<pov::Vector2d>::PrecomputedNumberGenerator' requested here
                return SequentialVector2dGeneratorPtr(new PrecomputedVector2dGenerator(factory, count));

Self referencing member in creator does not seems to be great for a reproducible pseudorandom generator (some compiler/architecture might force to 0, other might not... seems bad karma).

                           
             povmscpp.cpp:1875:4: warning: delete called on 'POVMS_MessageReceiver::HandlerOO' that is abstract but has non-virtual destructor [-Wdelete-non-virtual-dtor]
                        delete nodeptr->handleroo;
                        ^
povmscpp.cpp:1877:4: warning: delete called on 'POVMS_MessageReceiver::Handler' that is abstract but has non-virtual destructor [-Wdelete-non-virtual-dtor]
                        delete nodeptr->handler;
                        ^

Maybe just a missing keyword (virtual) in the header file ? Or is it harder ?

shelloutprocessing.cpp:260:28: warning: expression result unused [-Wunused-value]
        for (s = str.c_str(); *s; *s++)
                                  ^~~~

Why “*s++” ? why not just “s++” ?

renderfrontend.cpp:1165:57: warning: trigraph ignored [-Wtrigraphs]
                                        default:                                    t = "(???)";                            break;
 

I guess it’s not an intended trigraph. Might nevertheless perturb some compiler/result.

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.

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

see my post titled: “area light and radiosity problem?” in povray.binary.images [Edit - copied that post’s text here - clipka]

wondering about what’s going on here with this series of images. the radiosity and area light settings are unchanged from image to image, and all I did was radiosity on/off and area_light on/off (btw: using rad_def “Normal” settings)

the 1st image is radiosity only, the 2nd is area light only, and the 3rd combines them:

what’s up with blotches? change #5819/5820 (octree) or maybe something still with area lights?

Currently neither of these pages:

  http://www.povray.org/documentation/view/3.7.0/253/

  http://www.povray.org/documentation/view/3.7.0/90/

mention that the background can be transparent. Any normal user will try to give “background { ... }” a transparent color, see that it doesn’t work, and assume that POV-ray can’t do it.

The pages should mention the +UA command-line option, which enables the transparency.

Included math.inc into scene and recieved this fatal error from povray:

File '/usr/local/share/povray-3.7/include/math.inc' line 248: Parse Error: Expected 'string expression', float function 'vlength' found instead

Appropriate place in math.inc:

245 > #end
246 >
247 > // Distance between V1 and V2
248 > #macro VDist(V1, V2) vlength(V1 - V2) #end
249 >
250 > // Returns a vector perpendicular to V

Running newly-downloaded/newly-compiled POV-Ray 3.7.0, on Linux x86_64 system

There are times when scaling an entire scene up or down is difficult or just not feasible.

One suggestion is a global_settings option.

Also, I’ve noticed that in some situations, such as interactions between certain transparent objects, the epsilon seems to kick in quite early. Perhaps there could be situational or contextual epsilons, such as the “tolerance” of sphere_sweep or the “accuracy” of isosurface.

From synthetic post of Cousin Ricky in p.beta-test, 2013-06-24 circa 3:19 pm (MST)

William F Pokorny anonymous@anonymous.org wrote:
> It seems to be the case the gradient warnings are only generated if the
> isosurface is naked. If it is wrapped in an object as was the case with
> my thread safety example, we get no warnings.

Confirmed. If only I still had the concentration required to investigate
computer code.

#version 3.7;

#ifndef (MG) #declare MG = 40/9; #end
#ifndef (Naked) #declare Naked = no; #end

global_settings
{ assumed_gamma 1
  radiosity {} //force isosurface calculations from all directions
}

light_source { <-3.3125, 7.6250, -5.7374>, rgb 1 }

camera
{ location <0.0000, 1.0000, -5.6713>
  look_at <-0.7969, 1.2000, -0.0598>
  angle 10.7447
}

#include "functions.inc"

#if (Naked)
  isosurface
  { function { f_sphere (x, 0, z, (2660 - 40*y) / 9) }
    contained_by { box { <-80, 31, -24>, <-128, 56, 24> } }
    max_gradient MG
    pigment { rgb <1, 0.75, 0> }
    scale 1/128
    rotate -35 * x
    translate y
  }
#else
  #declare Test = isosurface
  { function { f_sphere (x, 0, z, (2660 - 40*y) / 9) }
    contained_by { box { <-80, 31, -24>, <-128, 56, 24> } }
    max_gradient MG
    pigment { rgb <1, 0.75, 0> }
    scale 1/128
    rotate -35 * x
    translate y
  }
  object { Test }
#end

On the command line, try:

declare=MG=1 declare=Naked=1

and

declare=MG=1 declare=Naked=0

To lose the warning, I had to declare the isosurface. Just wrapping the naked
isosurface in an object{} generated a warning.

Further analysis

if((Stage == STAGE_SHUTDOWN) && (mginfo->refcnt == 0))

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.

I’ve recently been working with the netpbm ppm format and I have hit what I believe to be a bug in the way ppm files are read – very likely a bug in all netpbm formats. I am aware of the long standing povray issue with the netpbm file formats header where the height and width need to be on the same line as the magic number though that is not a requirement of the official format. This bug is different.

Namely in working with a larger number of ppm files I hit cases where a few would fail with the message : “Possible Parse Error: Unexpected EOF in PPM file” though the ppm files are fine. What is happening is that the first byte of data after the line feed (LF) (Ubuntu linux 12.04) happens to have a carriage return (CR) value.

The code which is set up to interpret the netpbm headers is reading a lines with “file→getline (line, 1024);” and this line reading code is pulling in the first byte of data with the CR value as part of the line. When the read by binary data, 8 or 16 bits at a time, starts, the povray read code is offset into the data by one byte too many.

The result from 10,000 meters, if input values were completely random file to file, would be netpbm read fails for size that make no sense in 1/256 files. In practice & depending on data some might never see fails while an unfortunate few might almost always fail.

I’d make some argument any CR following a LF character should not be pulled in as part of the line read even on windows/dos systems where CRLF is the usual line termination order. I think though the real fix is better netpbm header reading code which more strictly breaks apart the header on the first whitespace character doing the last depth break, aware of the file size, so it can decide what portion of any valid sequence of whitespce characters after the decimal depth value is data and not whitespace.

The attached tarball when unpacked has both a passing and failing case. To run “povray fails.pov” or “povray works.pov”. The only difference between the two ppm files if the fails.ppm data is all 0x0D while works.ppm data bytes are all 0x0C. The image rendered is meaningless.

Thanks for your time.
Bill P.

After a long parse period and a relatively quick rendering, POVray gets stuck at 99% when rendering the attached file.

Rendered at 6144x3072px with antialiasing set to 0.3.

Can anyone confirm?

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

When using mesh_camera type ‘0’

The first line of the mesh output seems to be repeated resulting in incorrect light colour values.

If the first line of the texture is skipped then the values seem to be correct.

Height=36084

[640×360, AA 0.3]
Width=640
Height=36084
Antialias=On
Antialias_Threshold=0.3

should be:

[640×360, AA 0.3]
Width=640
Height=360
Antialias=On
Antialias_Threshold=0.3

On Windows 7 and newer operating systems, some programs are able to display their progress in the taskbar buttons.

Here is an example of Chrome downloading something and showing the progress in the taskbar:

http://www.winbeta.org/sites/default/files/news/oldfashinoned.jpg

Here is an example with Paint.NET instead:

http://www.getpaint.net/images/pdn351_superbarProgress.png

I think this feature would use fewer CPU resources than a) minimizing/maximizing the whole application window each time you want to check progress, or b) hovering the mouse over the taskbar button to show the thumbnails.

#fopen directive w/o OPEN_TYPE (yeah, I forgot it, some other languages have ‘read’ as default value)

expected behavior:
Parse error msg “line XXX, OPEN_TYPE missing in #fopen directive”, then stop.

observed behavior:
crash - Segfault err (core dump) in Parsing stage

minimal working example attached

Using a facet pattern in a normal map results in a unspecified error in Evaluate_TPat at the render stage.
This probably should be caught at parse time to give a more descriptive error and a line number.

Example:

sphere {
  0, 1
  texture{
    pigment{rgb <1,1,1>}   
    normal {
      facets
      normal_map {
         [0 bumps ]
         [0.5 facets ]
         [1 bumps ]
      }
    } 
  }
}

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.

20 library paths is a bit small given the sheer number of include files I’ve collected over the years. An increase in the number, and/or the ability to include wildcards in the search path, would be great.