If the image is more than 1270 pixels wide or more than 720 pixels high, animation fails with a segmentation fault during the second rendered frame. This happens after parsing is complete and the .pov-state file is created. The last message line is the “[Rendering...]” line. (There is also a separate, but possibly related, issue that the output display does not work for these renders.)

On one occasion, POV-Ray hung, and I had to ctrl-Z kill -9 out of it.

On another occasion, instead of the segmentation fault, I got the message:

povray: xcb_io.c:140: dequeue_pending_request: Assertion `req == dpy->xcb->pending_requests' failed.
Aborted

There is no crash when -D is used.

I have not run an animation this large in Windows, so I don’t know if it’s a problem there.

Neither problem occurs in POV-Ray 3.6.1.

I used the following source code:

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

Platform

Libraries

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

The +GD flag gives me an “Invalid parameter” error, whether on the command line or in a .ini file.

Debug_File= still works.

I reported this in povray.beta-test, but did not receive a response.

The problem occurs in both Windows 7 and in Linux.

As posted in povray.beta-test 2012-01-14 with the same subject.

OS Win7 32 bit

The following code fails with the following message:
Picture index out of range.
Picture index out of range.
Fatal error in renderer: Uncategorized error.
Render failed

The texture scale is relevant.

It does not fail in Pov 3.62
The image map can be downloaded from:
http://www.mmedia.is/~bjj/data/s_rings/sat_ring_color.png

(Attached)

#version 3.7;

global_settings {
adc_bailout 0.0039
ambient_light rgb <1.000,1.000,1.000>
assumed_gamma 1.00
irid_wavelength rgb <0.250,0.180,0.140>
max_trace_level 5
number_of_waves 10
noise_generator 3
charset ascii
}

background { colour rgb <0.000,0.000,0.000> }

#declare Ring_Texture1 =
texture {
uv_mapping
pigment {

image_map{
 png "sat_ring_color.png"
 interpolate 2
 map_type 0
}
rotate    <90.000,90.000,0.000>

}

finish {

ambient     rgb <0.100,0.100,0.100>
brilliance  1.000
crand       0.000
diffuse     0.600
metallic    0.000
phong       0.000
phong_size  40.000
specular    0.000
roughness   0.050

}

}

#declare Camera0 =
camera {
perspective
location <3843.816,38.892,-2660.667>
up y
right 1.333*x
angle 33.000
sky ←0.004,1.000,0.002>
look_at < 0.449, 18.943, 0.102 >
} end Camera0 disc { Disc0
0,y,4.400000,2.500000
texture{ Ring_Texture1 }

  scale     <750.000000,750.000000,750.000000>      // Fails 32 bit

scale <800.000000,800.000000,800.000000> Fails 64 bit
scale <600.000000,600.000000,600.000000> does not fail
rotate <0.000000,0.000000,-20.000000>
translate ←3500.000000,900.000000,900.000000>
} end Disc0 camera{ Camera0 } ///

parser fails to report when an illegal map_type is used. For example map_type 10 and map_type 100 doesn’t produce an error

There is a long animation to render.

computer 1 should render 0..799
computer 2 should render 800..1599

And after this, You have a bad surprise with the filenames.

animation799.png
animation0800.png

There should be a seting how many digits a file name in an animation should have.

This avoids, that there are series of pictures with 3 and other with 4 digit filenames.

BTW: All the experiences for this feature requests had been made during producing
http://roland.pege.org/2011-gusi-peace-prize/calculation-error.htm

I tried to render a candle’s flame (an object with interior made of emission media) against an Alpha background. In 3.6, the “flame” appears as a bright object against the alpha background; but in 3.7, the flame disappears against the alpha (as the attached scene will make clear, the “flame” is still visible against opaque background objects). I used the settings “Output_Alpha=true Output_File_Type=N”.

If there is another (better?) way to achieve a similar effect, I am open to using a work-around.

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.

Keyword Completion does not work for several names.
I miss it for animation related names like frame_number or final_frame.

Typing “fram{TAB}” just inserts a TAB character after “fram” instead of completing it to frame_number.

Independently of that bug, typing {TAB} repeatedly does not cycle through possible names:
“fr{TAB}” gives “frequency” and “fresnel” and that’s all.

In version 3.6 it worked well.

My system is Windows 7 64bit and PovRay is 3.7.0.RC3.msvc9.win64

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

REcently I installed POV-Ray tracing software in my mac OS X version 10.6.8. When I run the software its displaying a fatal error occured and the error number is -43. I’m new to POV-Ray...pls help me guys...

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.

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

How to do it: (with raddem.ini & raddem.pov from distributed scenes, copied in local directory)

1. run “povray raddem.ini” until frame 6 or more (irrelevant, at least frame 1 & 2 are needed), interrupt the render.
2. restart “povray raddem.ini +C”

It fails at frame 2 with
Possible Parse Error: Cannot find file ‘raddem.pov’, even after trying to append
file type extension.
Parse Error: Cannot open input file.
Fatal error in parser: Cannot parse input.
Render failed

The detection of frame 1 is fine.

in the sample scenes, animations/raddem/raddem.ini is not parsable by current versions of povray. (3.7RC3 and upto #5476)

Radiosity= is a gone away option.(from a bit of time in the 3.7 branch)

Certain types of errors are being reported twice. For example:

Parse Error: Expected ‘numeric expression’, } found instead
Parse Error: Expected ‘object’, undeclared identifier ‘foo’

The first error was a user typo when not enough parameters were specified, and the later when calling a yet to be declared object.

During investigation it was also discovered that improperly formed scale statements also produced the double error report: <scale 1,0.5,1>

Verified on linux and windows platforms.

I tried to use 3.7 RC3. This was my first time with 3.7.

I got source, configured and compiled it and installed into Debian with checkinstall. And then I tried to use it. First run was with -benchmark (it took about 9 minutes, ok). Then I tried very simple scene:

rekcahx@oah:~/pov$ povray +Iaa.pov
povray: This is a RELEASE CANDIDATE version of POV-Ray. General distribution is discouraged.
Failed to parse command-line option

I tried to debug with strace:

rekcahx@oah:~/pov$ strace -o debug.strace povray +Iaa.pov
povray: This is a RELEASE CANDIDATE version of POV-Ray. General distribution is discouraged.
Persistence of Vision™ Ray Tracer Version 3.7.0.RC3 (g++ 4.6.1 @
x86_64-unknown-linux-gnu)
This is a release candidate of POV-Ray version 3.7.0.
General distribution is strongly discouraged.

POV-Ray is based on DKBTrace 2.12 by David K. Buck & Aaron A. Collins
Copyright 1991-2003 Persistence of Vision Team
Copyright 2003-2011 Persistence of Vision Raytracer Pty. Ltd.

Primary POV-Ray 3.7 Architects/Developers: (Alphabetically)

Chris Cason         Thorsten Froehlich  Christoph Lipka   

With Assistance From: (Alphabetically)

Nicolas Calimet     James Holsenback    Christoph Hormann   Nathan Kopp       
Juha Nieminen     

Past Contributors: (Alphabetically)

Steve Anger         Eric Barish         Dieter Bayer        David K. Buck     
Nicolas Calimet     Chris Cason         Aaron A. Collins    Chris Dailey      
Steve Demlow        Andreas Dilger      Alexander Enzmann   Dan Farmer        
Thorsten Froehlich  Mark Gordon         James Holsenback    Christoph Hormann 
Mike Hough          Chris Huff          Kari Kivisalo       Nathan Kopp       
Lutz Kretzschmar    Christoph Lipka     Jochen Lippert      Pascal Massimino  
Jim McElhiney       Douglas Muir        Juha Nieminen       Ron Parker        
Bill Pulver         Eduard Schwan       Wlodzimierz Skiba   Robert Skinner    
Yvo Smellenbergh    Zsolt Szalavari     Scott Taylor        Massimo Valentini 
Timothy Wegner      Drew Wells          Chris Young       

Other contributors are listed in the documentation.

Support libraries used by POV-Ray:

ZLib 1.2.3.4, Copyright 1995-1998 Jean-loup Gailly and Mark Adler
LibPNG 1.2.44, Copyright 1998-2002 Glenn Randers-Pehrson
LibJPEG 62, Copyright 1998 Thomas G. Lane
LibTIFF 3.9.5, Copyright 1988-1997 Sam Leffler, 1991-1997 SGI
Boost 1.46, http://www.boost.org/
OpenEXR, Copyright (c) 2004-2007, Industrial Light & Magic.

Parser Options

Input file: aa.pov
Remove bounds........On 
Split unions.........Off
Library paths:
  /usr/share/povray
  /usr/share/povray/ini
  /usr/share/povray/include
Clock value:    0.000  (Animation off)

Image Output Options

Image resolution.....320 by 240 (rows 1 to 240, columns 1 to 320).
Output file..........aa.png, 24 bpp PNG
Dithering............Off
Graphic display......Off
Mosaic preview.......Off
Continued trace......Off

Information Output Options

All Streams to console..........On 
Debug Stream to console.........On 
Fatal Stream to console.........On 
Render Stream to console........On 
Statistics Stream to console....On 
Warning Stream to console.......On 

[Parsing...]

Parse Time:       0 hours  0 minutes  0 seconds (0.001 seconds)
            using 1 thread(s) with 0.000 CPU-seconds total
Bounding Time:    0 hours  0 minutes  0 seconds (0.000 seconds)
            using 1 thread(s) with 0.000 CPU-seconds total

Quality:  9
Bounding boxes.......On   Bounding threshold: 3
Antialiasing.........Off

[Rendering...]

Photon Time:      No photons
Radiosity Time:   No radiosity
Trace Time:       0 hours  0 minutes  0 seconds (0.016 seconds)
            using 4 thread(s) with 0.036 CPU-seconds total

I/O restrictions:          disabled
X Window display:          enabled (using SDL)
Supported image formats:   gif tga iff ppm pgm hdr png jpeg tiff openexr
Unsupported image formats: -

Build architecture:  x86_64-unknown-linux-gnu
Built/Optimized for: x86_64-unknown-linux-gnu (using -march=native)
Compiler vendor:     gnu
Compiler version:    g++ 4.6.1
Compiler flags:      -pipe -Wno-multichar -Wno-write-strings -fno-enforce-eh-specs -s -O3 -ffast-math -march=native -pthread

Hello,

this bug report relates to this thread: http://news.povray.org/povray.beta-test/thread/%3Cweb.4e0064d9a3970d212b256d410%40news.povray.org%3E/

In /unix/unixoptions.cpp around line 817:

while ( !Stream.eof() )
{
	// get and preprocess line
	std::getline(Stream, line);
	line = pre_process_conf_line(line);
	++line_number;
	// skip empty line
	if(line.length() == 0)
		continue;
        [...]
}

`Stream.eof()` could never be true as well as `line.length()` always can be zero, leading to an endless loop. In my case, the problem occurred due to my ~/.povray/3.7/povray.conf being a directory instead of a file.

To fix the problem, one has to consolidate this loop by not only checking for eofbit, but also for failbit and badbit of `Stream`. The getline() method on a directory does not set the eofbit, but it sets fail and bad (test: http://codepad.org/RiZGo3ia). According to http://www.cplusplus.com/reference/iostream/ios/operatornot/ fail and bad can be checked for by `!Stream`. A simple `if (!Stream) break;` within the loop fixes the problem (patch file attached).

Are there more missing checks on iostreams like this in the code? :) They should definitely be fixed.

Furthermore, one could think about using the boost filesystem library to be able to distinguish files and directories to provide good error messages.

Hope that helps,

Jan-Philip Gehrcke

For the next beta version, could you please create a new desktop icon? I keep clicking on the wrong version.

It would be nice when quitting a render if the remaining space were filled with empty pixels. That way the partial render will still be viewable in all image apps.

UV-mapped textures for parametrics are broken in POV-Ray 3.70 RC3, in cases where two (or more) parametrics overlap in a scene.

In the following scene, note how the texture per se is always taken properly from whichever parametric is in front, while the UV coordinates are erroneously taken always from the red parametric where both overlap, no matter whether it is in front or back.

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

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

#declare Param = parametric {
  function { u*v*sin (15*v) },
  function { v },
  function { u*v*cos (15*v) }
  0, 1
  contained_by { box { -1,1 } }
  accuracy 0.002
  precompute 15 x,y,z
  rotate 180*x
  translate  <0.3,0.5,0>
}

object {
  Param
  uv_mapping
  texture {
    pigment {
      gradient x frequency 3
      color_map {
        [0 color red .5 ]
        [1 color red 1 ]
      }
    }
  }
}

object {
  Param
  uv_mapping
  texture {
    pigment {
      gradient x frequency 7
      color_map {
        [0 color green .5 ]
        [1 color green 1 ]
      }
    }
  }
  rotate y*180
}

POV-Ray 3.62 renders the scene properly.

As this bug has been found during code inspection, the uderlying cause has already been identified; I’m currently working on a fix.

in change #3319, csg got a new computation for its weighted textures.

But I’m confused by the computation of the weight: (circa end of csg.cpp file)

COLC weight = 1.0f / min(COLC(textures.size() - firstinserted), 1.0f);

I would have used a max() rather than a min().

It is transparent when there is only one texture, but:

• should there be no texture (an error...): it would be a division by 0
• should there be more than 1, the weight of each would be 1. which is without consequence UNLESS there is already some other textures in the list. The right value (from previous code) was 1/n

Or did I get a confusion about min() ?

min(0,1) == 0
min(4,1) == 1

Using max would protect against the division by 0 and the right value when multiple textures are used.

Any thought ?

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

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

#local f = 1;
A()

This gives:

File 'bug.pov' line 2: Parse Error: Attempted to redefine float identifier as
 function identifier.

The problem is that this makes using functions in library macros difficult. Basically, they must have a globally unique name that’s not used in any of the macros or files that call the macros. #undef doesn’t really help, because it destroys the identifier in the calling scope.

For example, one of the macros in the standard include files names a function “fn”, so this doesn’t work:

#include "transforms.inc"

#local fn = 42; // fnord?
#local fn_pos = vtransform(x, transform { rotate 30*y } );

The reason for this restriction is explained in Parse_RValue in source/backend/parser/parse.cpp:

    // Do NOT allow to redefine functions! [trf]
    //   #declare foo = function(x) { x }
    //   #declare foo = function(x) { foo(x) } // Error!
    // Reason: Code like this would be unreadable but possible. Is it
    // a recursive function or not? - It is not recursive because the
    // foo in the second line refers to the first function, which is
    // not logical. Further, recursion is not supported in POV-Ray 3.5
    // anyway. However, allowing such code now would cause problems
    // implementing recursive functions after POV-Ray 3.5!

In this case the restriction is applied too broadly: it should be safe to redefine anything other than a function to a function and still avoid it looking like recursion. In fact, there’s a restriction in Parse_Declare specifically to prevent redefining functions.

In vfe/unix/unixoptions.cpp, -V is defined as a synonym for -​-version, overriding its general meaning of Verbose=off.

A scene of a hollow sphere viewed from the inside:

difference {
    sphere { 0, 100 }
    sphere { 0, 99 }
    pigment { rgb 1 }
    finish { ambient .4 }
}

global_settings {
    radiosity {
        error_bound .1
    }
}

Rendering produces dark splotches at the centers of the pretrace blocks, as shown in the attached image. Blocks rendered earlier have darker splotches. They also differ in shape between renders even with +HR (but not with +WT1).

Turning “always_sample” on, changing “pretrace_end” to 0.01, or increasing “count” past 1000 makes them imperceptibly faint (they can still be seen by increasing image contrast).

This is possibly a bug, as 3.6 doesn’t produce these artifacts regardless of additional settings.

povray.beta-test thread

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.

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 .

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

Given the following two statements, a missing closing brace in the function declaration fn should throw a parse exception; instead it causes a memory access violation when trying to use fn in the second delcaration:

#local fn = function { 
  pigment { image_map { png "MultiPassBlobs3.png" gamma 1 map_type 0 once }} 
#local clr = fn(0,0,0);

The documentation says:

“-J Sets aa-jitter off”

However, it seems to have no effect. -J0 will turn off jittering.

While testing if the png support was working, I tried 3.7.0rc3 on NetBSD-5.99.45/amd64, and had the following problems:

1. lseek64 (used in source/base/image/image.cpp) is not portable, and not necessary on NetBSD (off_t there is large-file-safe)
2. unix/Makefile.am doesn’t add -lboost_thread to povray_LDADD, which breaks linking the executable.
3. vfe/unix/platformbase.cpp uses CLOCK_THREAD_CPUTIME_ID, which is not provided on NetBSD (I hacked around it by defining the symbol to “0”, but that’s of course not a correct fix).
4. vfe/unix/platformbase.cpp uses CLOCK_PROCESS_CPUTIME_ID, which is not provided on NetBSD – it’s called CLOCK_REALTIME like on FreeBSD, so we could just add defined(NetBSD) to the FreeBSD case, except for point 3.
5. vfe/unix/vfeplatform.cpp uses WEXITSTATUS. For this, sys/wait.h should be included. The obvious fix is
#ifdef HAVE_SYS_WAIT_H
# include <sys/wait.h>
#endif
but this also needs a check in the configure script.

Fixing all this, I get it to build, but core dump when run against the demo file from http://www.csb.yale.edu/userguides/graphics/povray/demo.pov.html.
Backtrace is
Program terminated with signal 11, Segmentation fault.
#0 0x00000000004ac479 in boost::gregorian::date::date ()
(gdb) bt
#0 0x00000000004ac479 in boost::gregorian::date::date ()
#1 0x00000000004d29f7 in boost::gregorian::date::date ()
#2 0x0000000000479a85 in std::vector<std::string, std::allocator<std::string> >::operator= ()
#3 0×0000000000461570 in std::vector<std::string, std::allocator<std::string> >::operator= ()
#4 0x00000000004656c7 in std::vector<std::string, std::allocator<std::string> >::operator= ()
#5 0x00000000005efc9f in Imf::TypedAttribute<std::string>::typeName ()
#6 0x00000000005fd890 in Imf::TypedAttribute<std::string>::typeName ()
#7 0x00000000005fe5d8 in Imf::TypedAttribute<std::string>::typeName ()
#8 0x000000000045d6dc in std::vector<std::string, std::allocator<std::string> >::operator= ()
#9 0x00007f7ffd80d9cf in thread_proxy ()

from /usr/pkg/lib/libboost_thread.so.1.45.0

#10 0x00007f7ffd00b24e in pthreadcreate_tramp (cookie=<value optimized out>)
at /archive/cvs/src/lib/libpthread/pthread.c:473
#11 0x00007f7ff8871780 in _lwp_park50 () from /usr/lib/libc.so.12

Please advise on how to proceed.

povray +Imesh_camera.pov +Omesh_camera.png +FN +W800 +H600 produces a “Failed to parse command-line option” error. when I rename my pov source file to ess_mesh_camera.pov it runs fine. seems to be pointing to a clash with the +im option. i also had another file that renaming it got me going.

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

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 .

Using interpolated image_maps in functions results in pixel-sized dot-artifacts when using the functions back into pigments.

This problem doesn’t shows using the same code on POV-Ray 3.6.

I qualified it as “low severity” because is not going to happen to most users: it will show only when using some advances techniques, for example when you want to decompose an image_map into the RGB components, perform operations, and mixing them back with an averaged pigment (example attached).

couple of observations:

if no photons are gathered (hey it happens ... my typo) when attempting to save a photon map the warning message just indicates that it couldn’t save the map, maybe the message could be enhanced to say something like: No photons were gathered so no map information was saved. At first I thought something had changed in my I/O restrictions (I’m writing to an image directory not current or work directory)

when reading a previously saved photon map there is no indication that it was read in other than the end stats showing a small amount of photon time. I don’t recall but didn’t v3.6 indicate that the a previously saved map was being used? Just for the heck of it I moved the map file aside and it did prove to me that it was indeed being input. Some sort of message at the time the file is read in might be helpful.

I got a 29023 Segmentation fault ... but it was NOT repeatable. I reran the render job repeatedly and it displayed appropriate error message. I had renamed a texture identifier but missed an occurrence inside texture_map.

FYI: I did a build off the depot last evening.(21:13)

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.

When POV-Ray 3.70 is run on a terminal, on an unix shell, and the user hits ctrl-Z to suspend (stop) POV-Ray, rather than stopping as expected, POV-Ray just reports that it did receive the signal, as if to laugh at the user “I’m not obeying your puny stop attempts”. It

The default action (as happens if the SIGTSTP signal is not trapped) would be much better, and is usually safe also in multithread programs.
It takes actual effort to _ignore_ the TSTP signal (namely, to trap that signal), so the current behavior is definitely a dysfeature, probably an oversight by whoever programmed the signal handler.

Also, when the terminal window is resized, POV-Ray needlessly reports that it received a signal number so-and-so (the number of SIGWINCH), adding irrelevant noise to its terminal output. Both signals (SIGTSTP and SIGWINCH) should simply be excluded from the signal trapping mask. I guess there are also other signals that are needlessly captured. It would be better to capture only those signals that an action is needed for.