POV-Ray

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

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

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?

Many people clearly miss a simple for-loop construct in povray. It is indeed true that probably at least 99% of #while loops out there have the form of a simple for-loop. It’s much rarer to have to use more exotic forms of looping supported by the #while mechanism. Thus it would make sense if a #for construct would be added which would make writing such loops much easier and convenient.

The only remaining question would be the syntax.

IMO the for-loop construct should implicitly declare a local variable of a specified name, automatically increment it during the loop, and then undefine it after the loop ends. It could perhaps be something along the lines of:

#for(<identifier name>, <initial value>, <final value> [, <step>])
  <loop body>
#end

Example:

#for(Counter, 1, 10) // 'Counter' gets values 1, 2, 3, ..., 10
  #debug concat(str(Counter, 0, 0), "\n")
#end
#for(Counter, 1, 10, 3) // 'Counter' gets values 1, 4, 7, 10
  #debug concat(str(Counter, 0, 0), "\n")
#end

I think this syntax ought to be relatively easy to implement (compared to more “traditional” syntaxes, such as something like “for Counter = 1 to 10” or the C syntax, which would be a lot more complicated).

Of course this raises a couple of questions:

1) What happens if ‘Counter’ was already declared as an identifier? One of three possibilities comes to mind:

• The ‘Counter’ in the for-loop replaces the previous identifier, as a regular #local command would.

• The ‘Counter’ in the for-loop hides the identifier for the duration of the loop, and unhides it afterwards.

• A syntax error is given (ie. the identifier name must be unused).

2) Should the user be able to modify the counter variable from inside the body of the loop? Something like this comes to mind as viable:

// Prints the values 1, 2, 3, 9 and 10
#for(Counter, 1, 10)
  #debug concat(str(Counter, 0, 0), "\n")
  #if(Counter = 3) #local Counter = 8; #end
#end

Alternatively the counter variable could be read-only.

Additionally, it could be nice if #break could be used to immediately jump out of the current loop (either #while or #for).

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.

The function of the “Debug_File=” .ini option has changed from 3.6 to 3.7.37a.
In 3.6, when rendering multiple frames, a debug file would be created that then appended the debug lines for each frame into the file. It was therefore able to have debug data that identified what parameters were used in which frame in case a frame did not have the desired effect.

In 3.7.37a, the debug file does not perform this function. Instead it creates a new debug file (overwriting the prior) with each new frame. Therefore the debug data is only useful for the final frame (or wherever the render was halted). This is useful for a single frame render or for identifying a fault within a series of frames (because only the last one will remain) but it is not useful for many frames that render successfully.

This problem does not cause any rendering errors or other defects. The debug file specified will only contain the debug data for the last frame rendered.

Per discussion in the forum it was unknown if this was a bug or “feature”. At this time it is causing me a problem so I am submitting the bug. No related bugs were found searching for “output” or “debug” in any status.

Operating System in use is Windows XP. I cannot test 3.7.37a in additional OSes, but it does not seem like it would be OS-specific.

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.

Many programming languages support an indeterminate number of parameters in functions/macros.

JavaScript for instance supports an “arguments” object.

Lua for instance supports the “args” object.

I would like to see that added to POV as well.

Here’s an JavaScript example:

function ArgTest(a, b){
   var i, s = "The ArgTest function expected ";
   var numargs = arguments.length;     //Get number of arguments passed.
   var expargs = ArgTest.length;       //Get number of arguments expected.
   if (expargs < 2)
      s += expargs + " argument. ";
   else
      s += expargs + " arguments. ";
   if (numargs < 2)
      s += numargs + " was passed.";
   else
      s += numargs + " were passed.";
   s += "\n\n"
   for (i =0 ; i < numargs; i++){      //Get argument contents.
   s += "  Arg " + i + " = " + arguments[i] + "\n";
   }
   return(s);                          //Return list of arguments.
}

Request a system variable to test whether a scene file has been included by another scene file.

For instance:

#if (is_included)
  camera {...}
#end

Using the concat function is tedious. Why not just have an operator with which to concatenate strings?

“Hello " + “world!”

“Hello " . “world!”

...for instance nVidia’s CUDA architecture, discussed here and other places.

General consensus is that it’s not worth the effort if only a partial set of POV-Ray’s features are possible.

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

In the folder “ready made scenes”, there is the file “B0 - Basic scene 11 - pure white background.txt”.
The text string to be rendered lacks the “e” in “pure”. Unfortunately, this makes the typo visible in the “Insert menu” preview image.

If the “e” is added, the text needs to be scaled a bit smaller (0.43 instead of 0.44) to fit inside the view.

The following code contains a possible “fix” (whatever).
It would be great if someone could fix this easy issue:

text { ttf "arial.ttf", "pure white background", 0.02, 0.0 // thickness, offset
       texture{ pigment{ color rgb<1,0.6,0>*0.5 } 
                finish { phong 0.1 }
              } // end of texture

       scale<1,1.25,1>*0.43
       translate<-2.10,-0.30,0.00 >
      } // end of text object ---------------------------------------------

.../scenes/objects/fractal2.pov

in global_settings  "max_trace" should be "max_trace_level"

.../scenes/advanced/diffuse_back.pov

in global_settings  assumed_gamma statement should not be followed by a semicolon

.../scenes/advanced/blocks/stackernight.pov

in global_settings  "assummed_gamma" should be spelled "assumed_gamma"

.../scenes/portfolio/*.pov

in all files other than _empty.pov the parse stops at the lines containing "[frame_number-1]" I'm guessing it should be "[frame_number]-1"