POV-Ray

original post on povray.beta-test:

POV-Ray 3.7.0.RC3 on Slackware 13.0 x86_64.
I pointed povray to use the calibri.ttf font over on my Windows 7 partition.
The result is garbled - strange letters with accents appear instead of the
expected text. (KDE's kfontview opens calibri.ttf OK, with nothing strange).

Pointing povray to use other fonts of Win7, e.g. comic.ttf and arial.ttf, was
OK.

I solved the problem by pushing calibri.ttf through fontforge and resaving it
as mycalibri.ttf.

Cheers,
Peter

Confirmed with development version on Windows XP x64.

Possibly a similar problem as  FS#162 .

original posting from povray.beta-test:

I get this error message:
"Parse Error: bad allocation  Render failed"
- after the code below has been running for about 3 seconds.

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7

#version 3.7;

#while (true)
  #local Fn = function { transform { translate <0, 0, 0> } }
  #undef Fn
#end // while

// ===== 1 ======= 2 ======= 3 ======= 4 ======= 5 ======= 6 ======= 7

I'm using POV-Ray for Windows - Version 3.7.0.RC3.msvc9-sse2.win32
The operating system is Windows XP.

With the code above, the error messages has so far appeared every time
right after 3318K tokens have been parsed. But with other versions of
my code, the error message does not always show up. (Sometimes the
render finishes and sometimes the parsing stops at different "times".)

[...]

Other users report no error message, but memory consumption rising to about 1.2 GB.

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

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

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

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.

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

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

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

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.

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)

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.

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

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.

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

The following SDL code causes a hard crash during parsing if _3024_dot_dat is undefined:

light_source {
    <0, 0, 0>
    color rgb 0.5*<1,0.905882,0.211765>
    fade_distance 500
    fade_power 1.6
    looks_like {_3024_dot_dat texture {
        pigment { rgbf <1,0.905882,0.211765,0.90> }
        finish { ambient 0.6 diffuse 0 phong 0.5 phong_size 40
            reflection 0.9
            refraction 1 ior 1.25
            }
        }
}    } 

Thin tori exhibit artifacts in 3.7.0 RC3 when the camera is placed inside the torus close to its “center plane”, as can be demonstrated with the following scene:

camera {
  location  <0.0, 0.0, -0.5>
  direction 1.5*z
  right     x*image_width/image_height
  look_at   <0.0, 0.0,  0.0>
  angle 1
}

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

torus {
  1, 0.001
  texture { pigment { color red 1 } }
}

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

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.

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.

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

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

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

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.

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

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

Consider the following script:

  #fopen F "foo.txt" read
  #read (F, Foo)
  #debug concat ("'", Foo, "'\n")
  #fclose F

Now assume that foo.txt erroneously contains unquoted text (which will result in a parse error):

  Blah

When the error is reported, POV-Ray for Windows will helpfully open foo.txt, but any attempt to save a corrected version of foo.txt will fail until you exit the POV-Ray GUI, presumably because foo.txt is not properly closed by the parser.

I reinstall a system, (so ~/.povray was not existant), and then
installed povray from sources, as a normal user (excepted the
installation step):

$ ./configure ...
$ make
$ make check
$ sudo make install

I find these steps pretty much standard.

The problem I’m noticing is that the $HOME/.povray hierarchy get owned
by root (hey, it’s *MY* directory !). There is a chown in the Makefile
for the target files (povray.ini & povray.conf), as well as subtree but:

* povowner & povgroup are hard coded to 0 (I would expect a copy of the
owner & group of $HOME, wouldn’t I ?)

For getting povowner, I would suggest `stat -c “%u” $HOME`
For povgroup, `stat -c “%g” $HOME`

Are they portable enough ? (I could ask on Monday a Solaris system, but
I do not have bsd and the other flavours of unix)

(Stat is in section 1 of man, part of gnu coreutils, /usr/bin/stat)

Side note: This is fine to install for the local user, but new later
users could benefit also from a ~/.povray/3.7/ subtree ; what about also
filling the /etc/skel (when available) ? (and in /etc/skel, root owner
is fine!)

~scenes/advanced/optics.pov not rendering correctly. See the post in povray.beta-test “Photons not working as expected” for additional information.

Turns out the crand feature, which depends on a real random number generator (and hence has threading issues) was disabled early on during 3.7 development, and hasn’t been fixed yet. The code is commented out in line 2426/2427 of trace.cpp.

Suggestion:

In file screen.inc, have macro Screen_Object() set no_radiosity on the object.

POV-Ray fails to accept UTF-8 encoded files with a leading Byte Order Mark.

According to the code it was intended to recognize a leading BOM (or, more precisely, leading non-ASCII code sequences) and automatically switch to UTF-8, so this must be considered a bug rather than a missing feature.

I’ve got an ini file that looks like this:

Post_Frame_Return=U
Post_Frame_Command=notepad.exe

And when I render a scene using that ini file, it renders correctly but then
gives me this error:

Render halted because the post-frame shell-out (’notepad.exe’) requested POV-Ray
to generate a user abort.
Render failed

.....and it doesn’t open notepad.

I’ve unchecked the “Disable Starting Other Programs” and I’ve tried various
variations on what exe to run and whether to do it Pre/Post Frame/Scene, and
nothing has worked.

I’ve had a series of what appear to be a hang up’s. They passed parse, reported some stats and issued the Rendering... message and opened the preview window, but never progressed. They continued to accumulate cpu time until I eventually had to kill -9, softer didn’t work.

I’ve been dismissing them up until now wanted to speak up because I finally got this crash:

29623 Segmentation fault

Here’s some observed behaviors:

In my scene I have a Round_Box_Union with /just/ a pigment that rendered fine, but when I added a wood texture from the distribution includes, it hung up after I tried to transform the texture in any way. Tried other distribution textures ... same thing.

I spent time going through different scenarios looking for a common cause (thinking I’m doing something wrong). Eventually I arrived at the point that I killed a hung render, and restarted the same render with no changes. Sometimes it would render, sometimes not ... I finally got the above mentioned Round_Box_Union to behave with a simple reflective texture, and the rounding parameter had to be above 0.1 ... I settled at 0.125. OK by now you’re thinking WTF right?

No more problems until I accidentally (typo) put an additional light_source at the same location as another light_source. It also hung sometimes, and rendered fine sometimes after a kill ... no SDL changes.

Now I can’t tell you exactly what I was doing when the seg fault happened, but I /do/ know I just restarted the render with no changes. I’m starting to think there’s some kind of instability happening here. I realize that I’m probably the only team member spending any real time with the application, so none of you probably haven’t noticed anything suspicious.

Any comments ... ideas ... suggestions?

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.

The documentation states mesh_camera 0 should produce 1 pixel per index but it currently seems to produce 1 lighting pixel per face.

This output seems fairly meaningless as using this data for vertex colours (presumably the intention for mesh_camera 0) would result in a flat shaded model.

Logically it would make more sense to output 1 pixel per vertex instead of 1 pixel per face. Another solution might 1 pixel per face index (as per documentation) although POV would need to record which indices had already been computed otherwise it could end up duplicating computation.

At the moment I’ve written a code workaround for my exporter which produces a special mesh but this is obviously a much more complex solution to a fairly simple problem.

How to reproduce:

# An empty directory, an empty source file.
$ mkdir test && cd test && touch test.pov
# Generate the first 24 frames.
$ povray -D +KFF24 +Itest.pov +Otest.png
# Try to generate the 25th frame.
# `25' after `+KFF' can be changed to any integer greater than 24.
$ povray -D +C +KFF25 +Itest.pov +Otest.png

What happens:

==== [Parsing...] ==========================================================
Possible Parse Error: Cannot find file 'test.pov', even after trying to append
 file type extension.
Parse Error: Cannot open input file.
Fatal error in parser: Cannot parse input.
Render failed

OS: Gentoo AMD64 unstable
POV-Ray version: 3.7.0 rc5

Using POV-Ray 3.7 RC6 64bit for Windows
I have problems in the POV-Ray editor with ‘backspace’:

When using backspace at start of line
it does not only kill the return/line feed, but also
everything of the line what’s beneath the upper line.

Sample: (here ‘|’ is used for the current cursor position!)

//--------------------------------------
texture { pigment{ Red }
|         normal { bumps 0.5 scale 0.1 }
//--------------------------------------

hitting backspace results in:

//--------------------------------------
texture { pigment{ Red }| 0.5 scale 0.1 }
//--------------------------------------

and not as expected:

//--------------------------------------
texture { pigment{ Red }|         normal { bumps 0.5 scale 0.1 }
//--------------------------------------

With 3.6.2 and with RC3 (latest old beta I found on my computers)
this was no problem!

I already reported this on 17-Sept-2012 at
http://news.povray.org/povray.beta-test/thread/%3C5056f452%241%40news.povray.org%3E/

As I posted yesterday to the POV bugreports, I observed a bug with the #write directive, having forgotten the closing bracket. I looked a little bit closer and found different behaviours of POV with different array sizes.

With ArrayDim=100 (please look at the attached SDL-code, which is reduced as much as possible and produces only the bug and no scene) one get the Parse Error: “Expected ‘string’, End of File found instead” and the last line is highlighted. With ArrayDim=1024 you get an Stack Overflow and POV crashes.

I observed this at two different core i7 windows machines. On one of them (16 GB RAM, if this is of importance) the threshold between both behaviours was between 300 and 400. Hope this helps.

Best regards,
Michael

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.

Output images are 0.5 pixels too right and 0.5 pixels too down (mesh_camera_bug.pov).

The error is cumulative when image files are used again as texture (run 10 times mesh_camera_bug_reuse.pov).

This can be compensated by adjusting UV maps (mesh_camera_fix.pov and mesh_camera_fix_reuse.pov).

Tested with and without anti-aliasing.

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.

Recently, I have been rendering an animation with POV-Ray 3.7 RC 6 using radiosity, photons and backside illumination. Many frames contained artefacts like in the attached image file. Trying to eliminate those artefacts I observed the following:

• Rendering the same frame several times did not reproduce the artefacts or reproduced them differently. I.e., when I rendered a second (third, fourth, ...) time with +SF100 +EF100, the black space in the image was somewhere else or in some cases disappeared.
• With radiosity turned off, no such artefacts have happened since, even in the scenes where they happened with radiosity turned on.
• Turning off photons with radiosity still turned on did not remove the artefacts.
• Rendering with one thread on one CPU core instead of two threads on two cores did not change anything except the rendering time.
• Changing the radiosity settings I have not tried thoroughly, but at least raising or lowering count or error_bound does not seem to have any effect on this.

While POV-Ray was rendering, no other memory-intensive or CPU-intensive programs were running and POV-Ray itself did not report any error (just the usual warnings that some of the used features could change in future versions etc.). Render priotity was set to “high”.

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

I would like to suggest an additional feature regarding splines. POV-Ray’s spline objects (spline {}) are very useful to create animation paths as a function of time from reference points; however, in many cases you do not only need a position to place an object correctly, but also its velocity etc., e.g. if you are animating a car moving along a spline you do not only need to know where the car is at a given clock value but also in which direction it is going. If you want to rotate the wheels correctly you even need to know how this direction is currently changing.

In a nutshell, if you are using splines to create an animation path, you might not only need the spline value itself, but also the value of its first and second derivative. So I suggest adding an SDL capability to access these values like it is possible to access the spline value for a given parameter.

I do not think it would be too difficult to add a feature like this as far as the backend is concerned, since for computing a (cubic) spline you need the first and second derivatives anyway. (They are probably not being stored separately, but a polynomial is not that hard to differentiate.)

Indeed I do not know how an SDL language construct for it should look like (i.e. whether to use ' and ‘’ like in mathematics or a second spline function parameter).

In POV-Ray’s documentation it says:

3.2.2.2 Max Image Buffer Memory
This INI parameter sets the number of megabytes of RAM to allow for output image caching. If the output image happens to use more than this, a file backed temporary image is used instead.

I used this INI file option because the default value (128 megabytes) seemed insufficient. pov-state backend files were always created and they were remarkably larger than the resulting image (bmp) files. Consequently, I set

Max_Image_Buffer_Memory = 3096

in the INI file so that POV-Ray should, according to the documentation, now be able to use 3 gigabytes of RAM so no backend temporary file would be needed at all (this large they were never).

However, while POV-Ray was rendering I still discovered a pov-state file and it still had a similar size.

Now I am confused: did the INI option not work or have I misunderstood the documentation? If the former is the case, that would be a bug, wouldn’t it?

I tested both under Windows XP and Debian 6.0.5.