POV-Ray

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.

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.

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.

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

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

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.

Linux beta 32, 64bits, compiled from sources.

povray -w800 -h600 +a0.3 +kfi1 +kff78
-L/usr/local/share/povray-3.7/scenes/incdemo
-Ii_internal.pov +WT5 +R4 +AM1 +MB1

Important issue: +WT5 +MB1

Seems Fine for +WT1 +MB1
Also fine for +WT5 +MB9

The intersection with the containing box displays some two-shades of grey
random checkered patterns.
Size of square looks like size of renderering thread. Position too.

Impacted frames (of 78):
01, 02, 03, 30, 48, 74, 76.

The following (bogus) SDL code causes POV-Ray 3.7 beta to crash hard with an access violation:

#include "fubar.inc"
Bar(42)
#macro FooBar() #end

//fubar.inc
#macro Foo(Fnord) #end
#macro Bar(Ignord) Foo(23 #end

Setting File_Gamma=1.0 produces unexpectedly bright output files for most output file formats, as if File_Gamma was set to 2.2 instead.

The underlying problem is a bug that, when File_Gamma is set to exactly 1.0, causes the encoding gamma function to be undefined, which was not meant to happen in current versions, and instead was reserved for future versions to signal that a file-format-specific default encoding gamma should be used. The image file output handlers already support this, most of them choosing the sRGB transfer function, giving roughly the same output as setting File_Gamma=2.2.

As a preliminary workaround, users may want to set File_Gamma=1.02 (any value smaller than 0.99 or greater than 1.01 should do).

Lines 1217, 1241 and 1242 of benchmark.cpp must be change to use #declare instead of local for A and its elements.
(because A is returned by the macro)

	"#macro L_GetVN(ResSpl)\n"
	"   #local I = 0;\n"
	"   #declare A = array[ResSpl+1][2]\n"                      //  <============== this is line 1217
	"   #while (I<=ResSpl)\n"
	"      #local P0 = 0+<FnA(I/ResSpl), I/ResSpl, 0>;\n"
	"      #if (P0.x=0 & P0.z=0)\n"
	"         #local P0 = <1e-25,P0.y,1e-25>;\n"
	"      #end\n"
	"      #if (I=0)\n"
	"         #local P1 = 0+<FnA(((I-0.5)/ResSpl)), I/ResSpl, 0>;\n"
	"         #local P2 = 0+<FnA(((I+0.5)/ResSpl)), I/ResSpl, 0>;\n"
	"      #else\n"
	"         #local P1 = P2;\n"
	"         #local P2 = 0+<FnA(((I+0.5)/ResSpl)), I/ResSpl, 0>;\n"
	"      #end\n"
	"      #local P3 = vrotate(P0,<0,1,0>);\n"
	"      #local P4 = vrotate(P0,<0,-1,0>);\n"
	"      #local B1 = P4-P0;\n"
	"      #local B2 = P2-P0;\n"
	"      #local B3 = P3-P0;\n"
	"      #local B4 = P1-P0;\n"
	"      #local N1 = vcross(B1,B2);\n"
	"      #local N2 = vcross(B2,B3);\n"
	"      #local N3 = vcross(B3,B4);\n"
	"      #local N4 = vcross(B4,B1);\n"
	"      #local N = vnormalize((N1+N2+N3+N4)*-1);\n"
	"      #declare A[I][0] = P0;\n"                               // <============== this is line 1241
	"      #declare A[I][1] = N;\n"
	"      #local I = I+1;\n"
	"   #end\n"
	"   A\n"
	"#end\n"

Same update should also be reported into the distributed scene benchmark.pov

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.

Cone is not on good place when first base point is lower then end cap point.
Example:

cone { <0, 0, 0>, 2, <0, 1, 0>, 1 } - good
cone { <0, 0, 0>, 1, <0, 1, 0>, 2 } - bad

This is on 3.7 beta 35 version.

This item may need to be merged with item FS#81. This is another sphere sweep bug, though they are of different spline types.

The code is

#include "colors.inc"

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

light_source {
  <0, 0, 0>            // light's position (translated below)
  color rgb <1, 1, 1>  // light's color
  translate <-30, 30, -30>
}


#declare i_start = 0;
#declare i_stop = 3;
#declare i_step = 0.05;
#declare i_inc = i_start;
sphere_sweep {
  linear_spline                 // linear curve

  (i_stop - i_start)/i_step + 1,    // number of specified sphere positions
#while(i_inc<=i_stop)
  
  #declare y_coor = 0.23*sin(7.1*i_inc);
  <i_inc, y_coor, 0>, 0.05
        #declare i_inc = i_inc + i_step;
 
        
#end

pigment{color Orange}

}

I’ve tried to model this setup:
http://kschwebke.webng.com/povray/ior-interfaces/drawing.png with the following SDL:
http://kschwebke.webng.com/povray/ior-interfaces/rs2.pov.txt

A small overlap between the two transparent solids is needed, because a gap
would lead to total reflection. The camera in the test scene looks in the
direction of the ray in the setup drawing. The setup is surrounded with angular
markers, so one can easily read the final resulting looking angle.

POV-Ray 3.6.1 renders the expected result (~53° in the center of the screen):
http://kschwebke.webng.com/povray/ior-interfaces/rs2-35.jpeg

POV-Ray 3.7.0b35a (compiled Unix source) renders a different
(and in my opinion wrong) angle (~67°), however – for the very same scene file:
http://kschwebke.webng.com/povray/ior-interfaces/rs2-37b35a.jpeg

I’ve started a discussion about this issue in povray.beta-test: http://news.povray.org/povray.beta-test/thread/%3Cweb.4bba4677730ab9f3e8c084b40%40news.povray.org%3E/

All linked documents are also attached.

The code to attenuate transmitted photons according to surface texture was apparently duplicated during refactoring of the source code for version 3.7. Behavior has changed from 3.6 to 3.7 (beta.36) accordingly, as can be demonstrated with the following scene:

global_settings {
  assumed_gamma 1.0
  max_trace_level 10
  photons { spacing 0.02 }
}

camera {
  right x*image_width/image_height
  location  <0,2.6,-10>
  look_at   <0,0.75,0>
}

light_source {
  <500,300,150>
  color rgb 1.3
  photons {
    refraction on
    reflection on
  }
}

sky_sphere {
  pigment {
    gradient y
    color_map {
      [0.0 rgb <0.6,0.7,1.0>]
      [0.7 rgb <0.0,0.1,0.8>]
    }
  }
}

plane {
  y, 0
  texture { pigment { color rgb <1.0, 0.8, 0.6> } }
}

#declare M_Glass=
material {
  texture {
    pigment {rgbt 1}
    finish {
      ambient 0.0
      diffuse 0.05
      specular 0.6
      roughness 0.005
      reflection { 0.1, 1.0 fresnel on }
      conserve_energy
    }
  }
  interior {
    ior 1.5
    fade_power 1001
    fade_distance 0.9
    fade_color <0.5,0.8,0.6>
  }
}

#declare M_PseudoGlass2=
material {
  texture {
    pigment {rgbf <0.8,0.2,0.2,0.8>}
    finish {
      ambient 0.0
      diffuse 0.05
      specular 0.6
      roughness 0.005
      reflection { 0.1, 1.0 fresnel on }
      conserve_energy
    }
  }
  interior {
    ior 1.0
  }
}

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

box {
  <2.4,0,-2.3>, <2.6,4,0.3>
  material { M_PseudoGlass2 }
  photons { target 1.0 refraction on reflection on }
}

Reflections in multi-layered textures are broken in 3.7 betas, as can be demonstrated with the following scene showing two reflective hemispheres on a checkered plane:

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

default {
 finish { diffuse 0 ambient 0 specular 0 }
}

// ----------------------------------------

plane {               // checkered floor
  y, -1
  texture
  {
    pigment { checker color rgb 1 color blue 1 }
    finish{ diffuse 0.8 ambient 0.1 }
  }
}

// left hemisphere
intersection {
  sphere { 0, 1 }
  plane { x, -0.002 }
  texture {
    pigment { color rgb 1 }
    finish{ reflection { 0.5 } }
  }
  texture {
    pigment { color rgbt 1 }
    finish{ reflection { 0.4 } }
  }
  texture {
    pigment { color rgbt 1 }
    finish{ reflection { 0.1 } }
  }
}

// right hemisphere
intersection {
  sphere { 0, 1 }
  plane { -x, -0.002 }
  texture {
    pigment { color rgb 1 }
    finish{ reflection { 1.0 } }
  }
}

Note that the reflection parameters of the left, multi-layered hemisphere sum up to 1.0, i.e. the same value as used in the single layer in the right hemisphere.

The first attached file (test_3.6.2.png), rendered with POV-Ray 3.6.2, shows the expected output: Both hemispheres appear to have the same reflectivity.

The second attached file (test_3.7.0.beta37a.png), rendered with POV-Ray 3.7.0.beta.37a, shows a much brighter left (multi-layered) sphere.

As it turns out, in order to get the expected result with POV-Ray 3.7.0.beta.37a, the reflectivity of each layer must be divided by 3, 2 and 1, respectively (which obviously does not sum up to 1.0):

  ...
  texture {
    pigment { color rgb 1 }
    finish{ reflection { 0.5 / 3 } }
  }
  texture {
    pigment { color rgbt 1 }
    finish{ reflection { 0.4 / 2 } }
  }
  texture {
    pigment { color rgbt 1 }
    finish{ reflection { 0.1 / 1 } }
  }
  ...

unixoptions.cpp has a getenv(”HOME”) that does an assignment without checking to see if getenv returns NULL.

This causes an immediate and unceremonious segfault in those situations where $HOME is not set such as in the case where povray is launched by a daemon.

Best solution might be to set the home to /tmp and print a warning message about $HOME not being set.

FileBackedPixelContainer uses a FILE* to manage the backing store and under Linux/Unix defines fseek64 to be a kind of incantation of lseek64.

Since fseek64 and fseek64 have return values that are logical opposites this causes an exception to be thrown.

Moreover since the buffer size on a FILE is quite a bit smaller than a line of pixels (in terms of bytes), mostly what’s being done in this function is a lot of sloshing of bytes that don’t do much... which is to say that the intended caching mechanism is getting a very low hit rate now that povray is working in 32×32 pixel per-thread chunks.

The cache miss problem and the volume of bytes read/written grows exponentially as the size of the image grows.

Attached is a replacement function that seems to be working well and should produce a performance increase even under Windows. I originally went with simply fixing the fseek/lseek problem but saw a 10% decrease in render time on 2048×1024-sized images when I made the cache target smaller.

Multi-textured blobs are broken with 3.7 beta 40 when used inside an intersection, as can be demonstrated by the following scene:

#default { texture { pigment { rgb 1 } } }

camera {
  right x*image_width/image_height
  location  <0,1.5,-4>
  look_at   <0,1,0>
}

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

difference { blob {
  threshold 0.6
  sphere { < 0.75,   0,    0>, 1, 1 texture { pigment { color red 1 } } }
  sphere { <-0.375,  0.65, 0>, 1, 1 texture { pigment { color green 1 } } }
  sphere { <-0.375, -0.65, 0>, 1, 1 }
} }

With POV-Ray 3.7.0 beta 40, the entire blob is rendered with the default texture.

The same problem can be seen with “difference” or “merge” instead of “intersection”.

Omitting the CSG “envelope”, using “union”, or assigning the blob to a variable first and then using it inside an intersection, will yield the expected result.

POV-Ray 3.62 renders all variants as expected.

According to initial analysis, the problem appears to be caused by the dual use of the “MULTITEXTURE_FLAG”, which is used in CSG to indicate use of the “cutaway_textures” feature, and in blobs to indicate per-element texturing. (The same flag is also used in meshes to indicate per-face or per-vertex texturing, so similar problems are to expected there.)

My proposal is to use an entirely separate flag for the “cutaway_textures” feature (the blob and mesh can safely continue to share the MULTITEXTURE_FLAG).

I rendered attached .pov file with both 3.62 and 3.7RC1, and got different output between them.
In 3.7RC1, it looks like no_reflection option of the black sphere doesn’t work.

Trying to build povray-3.6 against png-1.5 fails spectacularly.

.../include/png.h:666: error: forward declaration of ‘struct png_info_def’ png_pov.cpp:1405: error: invalid use of undefined type ‘struct png_info_def’

appears a lot in the output.

The problem is that png-1.5 hides structure members from public view.

Note, this is not the same problem as  FS#144 .

#macro A()
  #local foo = function { x }
  foo
#end

#local bar = A();

This causes either a segfault, corruption detected by malloc, or “Parse Error: Unknown user defined function”.

After some debugging I think this is what happens.

In source/backend/parser/parse.cpp, Parser::Parse_RValue is called to define the value of bar. Get_Token is called, which invokes A() and which ultimately returns foo as a FUNCT_ID_TOKEN. This token is handled by CASE_VECTOR in Parse_RValue. The relevant clause calls Parse_Unknown_Vector to parse additional tokens (e.g. “foo ( 1 )”). There aren’t any other tokens, but in the process of determining that, #end is reached and Return_From_Macro destroys the symbol table of A, including foo.

So by the time the CASE_VECTOR clause decides that foo is a function identifier that should be copied, the function is destroyed (both the function itself and its number in the symbol table). So here:

    Temp_Data  = (void *) Copy_Identifier((void *)*Token.DataPtr,*Token.NumberPtr);

if *Token.DataPtr (in this case, a function index) was already overwritten, we get “Unknown user defined function”; if it still has the valid function number, it increments the reference count of the function (which has already been freed) back from 0, and we get a double-free later.

A similar problem occurs when foo is a spline.

A tentative patch for the function case is attached.

Hopefully platform specific, other ports are welcome to check their scaling code.

Reported originally in p.beta-test (28 january 2012) by Cousin Ricky (email dropped)

Symptom: crash on start of second frame rendering
Environment: Unix, with display of rendered picture, rendered picture does not fit at 1:1 on the display

Demo (adjust the H/W to your setting to get them larger, both or any of them):

global_settings { assumed_gamma 1 }
light_source { <-1, 1, -1> * 1000, rgb 1 }
sphere { 2.5 * z, 1 pigment { red 1 } }

povray +H2000 +W2000 +KI0 +KF1 +KFI0 +KFF10 code.pov

When aborting a render when there are unfinished blocks among finished ones, under certain conditions some of those blocks are skipped when continuing the render later.

When using the ‘background’ directive with a transparent color, for example:

  background { color rgbt <0, 0, 0, 1> }

the final image is still opaque (both the one displayed in the render window and the PNG actually saved to disk).

Expected behaviour is for it to be transparent.

I cannot edit any pages on wiki.povray.org, even after confirming my e-mail address.

This means that I cannot add any documentation, help improve the documentation, fix errors or help in any other way.

If you want contributions to the documentation, you should let users edit pages.

Thread safety issue in functions using splines. 3.7.0.RC7.

First vetting in p.bugreports where several users were able to reproduce the fail on the following systems:

1) Ubuntu 12.1 i7 920 using 3.7.0.RC7
2) Ubuntu 12.04, AMD 2431 CPU, Linux 3.2.0-45 kernel using 3.7.0.RC7 (g++ 4.6 @x86_64-unknown-linux-gnu)
3) POV-Ray 3.7.0.RC7 (icpc 13.1.0 @x86_64-unknown-linux-gnu)

 Intel(R) Xeon(R) CPU E5-2680 0 @ 2.70GHz

 uname -or
 2.6.32-279.14.1.el6.x86_64 GNU/Linux

 lsb_release -irc
 Distributor ID: CentOS
 Release:        6.3
 Codename:       Final

4) Confirmed with openSUSE 12.2.
5) Just to add to the system list: with Windows and a core i7 one yields the same result.
6) “Le_Forgeron” ran under Intel Inspector (XE 2013) and provided this feedback :

 ...
  that might be less than 60 seconds, but with Intel Inspector (XE 2013),
 it becomes 42:50 (just 14 data races, oh well, that's just so friendly).

 ID  Type Sources Modules State
 P1  Data race isosurf.cpp; mutex.hpp povray New
 P2  Data race mutex.hpp; povms.cpp povray New
 P3  Data race povray.cpp povray New
 P4  Data race povray.cpp povray New
 P5  Data race mutex.hpp; pov_mem.cpp; splines.cpp povray New
 P6  Data race mutex.hpp; pov_mem.cpp; splines.cpp povray New
 P7  Data race mutex.hpp; pov_mem.cpp; splines.cpp povray New
 P8  Data race recursive_mutex.hpp; scene.cpp; task.cpp; taskqueue.cpp;
 view.cpp povray New
 P9  Data race condition_variable.hpp; vfe.cpp; vfesession.cpp povray New
 P10  Data race condition_variable.hpp; unixconsole.cpp; vfesession.cpp
 povray New
 P11  Data race condition_variable.hpp; unixconsole.cpp; vfesession.cpp
 povray New
 P12  Data race unixconsole.cpp; vfesession.cpp; vfesession.h povray New
 P13  Data race unixconsole.cpp; vfesession.cpp povray New
 P14  Data race [Unknown]; unixconsole.cpp; vfesession.cpp
 libboost_thread.so.1.49.0; povray New

 Numbers 2, 3, 4, 8, 9, 10, 11, 12, 13 & 14 are related to the handling
 of session (and occur once or twice only, excepted #8, four times).

 Number 1 is about isosurface (adjusting gradient at isosurf.cpp:1099 vs
 1098 (testing its value), and copying the isosurface) (IMHO, rendering
 threads updating the object... not the best move without some
 atomic/protection (and not sure a DBL is/can be atomic)) (occurs 2505
 times).

 Number 5, 6 and 7 are about splines
 * sp->Cache_Type & Cache_Point, splines.cpp :803 vs :814/815 (2024 times)
 * sp->Cache_Valid, :805 vs :813 vs :904 (1770 times)
 * sp->Cache_Data, :807 vs :903 (5025 times)

 Only my 0.02¢ (yes, very cheap), but it seems to confirm

For test code see attached files or SplineThreadSafety.pov attachment to
p.bugreports and images were posted to p.b.images.

Issue shows up any time more than one thread is used. Use of AA tends to hide
the problem so do not use it if using the output image for testing.

Thanks.
Bill P.