POV-Ray

Due to a recent thread in povray.general (7th September 2013), I dive
into the code of height field creation.

There is 2 TODO in source/backend/support/imageutil.cpp, for
image_height_at() (circa line 512)

The first one is about using the index of palette-image: As far as *257
would indeed perform a better job to cover the full range than *256, it
would break backward compatibility with previous versions of povray (3.6
included) which only promoted the index as the Most significant byte,
keeping the least one at 0.

But on the second one, the new formula is plain wrong: (r*255+g)*255
should be (r*256+g)*255.
In previous versions, r*255 was the Most significant byte, and g*255 was
the least one.
Ergo, the value was r*255*256 + g*255, which can and should be only
factored as (r*256+g)*255;

I know it is damn late in the release schedule, but can that be either
be fixed before final official delivery or a memo added to the release
note that it would be fixed later and backward-bug will not be
maintained for that specific point (using rgb-8 or less bit per
channel-image for height field)

(it was not bugged in 3.6.1 nor before, it’s just that tiny little bit
of 3.7 that would should that bug)

If you look carefully at the attached pictures (povray +I... +H700 +W700 +A0.01) of scene and scene36, there is a significant difference at the top.
With 3.6, it matched exactly (hence the noise on the top pixels row) the view.
With 3.7, it cannot reach the top and leave a white area
(another difference is the slope on the side are also a bit more lower with 3.7, easier to spot when alternating the display of both pictures)

If you want to regenerate hf.png, it was rendered with povray 3.7RC7, +W400 +H400 +A0.01 +Ihf.pov

The white line at the bottom is expected, as the minimal value of the height field is “full green”

can not run POV-Ray on ubuntu 14.04, boost 1.54,

./configure COMPILED_BY=”Dmitry <my>”

...

Libraries
---------
checking whether to link with cygwin DLL... no
checking whether to enable static linking... no
checking for the pthreads library -lpthreads... no
checking whether pthreads work without any flags... no
checking whether pthreads work with -Kthread... no
checking whether pthreads work with -kthread... no
checking for the pthreads library -llthread... no
checking whether pthreads work with -pthread... yes
checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE
checking if more special flags are required for pthreads... no
checking for boostlib >= 1.37... yes
checking whether the Boost::Thread library is available... yes
checking whether the boost thread library is usable... no
configure: error: in `/home/di/workspace2/povray-3.7-stable':
configure: error: cannot link with the boost thread library

log in attach file

Hi,

I think I may have found a bug in the subsurface/radiosity features of Povray 3.7 attached image showing the issue and sample files required to reproduce. The original files (on povray forum images thread) had different radiosity settings but these ones show the problem and only take a few seconds to render the image without AA so probably better for bug fixing/testing etc.

Thanks

Sean

The following paraboloid renders correctly:

intersection
{ quadric { <1, 0, 1>, <0, 0, 0>, <0, 1, 0>, -1 }
  cylinder { 0, y, 1 }
}

However, when I extend the clipping cylinder downward:

intersection
{ quadric { <1, 0, 1>, <0, 0, 0>, <0, 1, 0>, -1 }
  cylinder { -y, y, 1 }
}

the object disappears completely in POV-Ray 3.7 and 3.7.1. In POV-Ray
3.6.1, it renders as expected.

POV-Ray 3.7.0.unofficial (self-compiled with g++ 4.8, but completely unaltered)
POV-Ray 3.7.1-alpha.8150025.unofficial
openSUSE 13.2 GNU/Linux

This scene file illustrates the problem:

// +w480 +h240
#version 3.6; //[sic]

global_settings { assumed_gamma 1 }

camera
{ location <0, 1, -7.5958>
  look_at <0, 1, 0>
  right 2 * x
  up y
  angle 43.1038
}

#default { finish { diffuse 0.6 ambient rgb 0.15618 } }

light_source
{ <-4.3125, 9.6250, -7.4695>,
  rgb 6856.3
  fade_power 2 fade_distance 0.10417
  spotlight point_at <0, 1, 0> radius 45 falloff 90
}

box
{ -<9, 11, 9>, <9, 11, 9>
  pigment { rgb 1 }
}

plane
{ y, 0
  pigment { checker rgb 0.05 rgb 1 }
}

intersection
{ quadric { <1, 0, 1>, <0, 0, 0>, <0, 1, 0>, -1 }
  cylinder { 0, y, 1 }
  pigment { green 0.5 }
  translate <-1.25, 1, 0>
}

intersection
{ quadric { <1, 0, 1>, <0, 0, 0>, <0, 1, 0>, -1 }
  cylinder { -y, y, 1 }
  pigment { green 0.5 }
  translate <1.25, 1, 0>
}

On the right side, there should have been a cylinder capped with a paraboloid. A thread has been started in povray.bugreports. Jerome has started to look at it.

The Rect data type needs to be renamed to avoid a clash with a Mac OSX declaration. It was originally called Rectangle, but this clashed with a Windows declaration. Something more POV-specific should be used, e.g. PovRect.

There can be square (32×32) blotches in partially transparent objects.

global_settings {
   max_trace_level 10
}

camera { 
   location <-30,10,5> 
   look_at <0,0,0> 
   angle 25 
}


light_source { 
   <-100,30,70> 
   rgb 1 
}

difference { // make a dome
  sphere { <0,0,0> 5 }  // ball
  sphere { <0,0,0> 4.9 } // hollow interior
  box { <-6,-6,-6> <6,1,6>  pigment { rgb <0,0,0> }}  // chop off bottom half
  pigment { rgbt <1,1,1,0.675> }
}

box { 
   <-6,-6,-6>, <6,0.99,6> 
   pigment { rgb <1,1,1> } 
   rotate <0,45,0>
} // sit it on a box

The parser is missing extra period characters when it parses a float as a vector component.

#local sample = <0.0.0.1,0,0>;

Doesn’t generate an error, but should.

Adding an AOI pattern is asked for fairly frequently.

In the following scene, the mesh object will always cast a fully-opaque shadow, even if the image has an alpha channel:

camera {
  location  <0.5, 1.0, -1.0>
  look_at   <0.5, 0.0,  0.5>
}

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

mesh {
    triangle { <0,0,0>, <1,0,0>, <1,0,1> uv_vectors <0,0>, <1,0>, <1,1> }
    triangle { <0,0,0>, <1,0,1>, <0,0,1> uv_vectors <0,0>, <1,1>, <0,1> }
    texture { pigment { uv_mapping image_map {png "FOOBAR.png"} } }
}

plane { y, -0.1 pigment { color rgb 1 } }

The following modification to the texture will give the expected results:

    texture { uv_mapping pigment { image_map {png "FOOBAR.png"} } }

The problem can be observed with both POV-Ray 3.7 (tested with beta.34), as well as 3.6 (tested with 3.6.2).

File output code for virtually all file formats performs gamma correction on unclipped color values, which leads to issues when color values happen to be negative for some reason and gamma does not happen to be an integer value such as 1.0 or 2.0. As a consequence, subsequent steps (clipping and converting to integer) apparently produce compiler-dependent results. Compiled with Microsift or Intel compilers, POV-Ray seems to write zero brightness in such cases, while compiled with g++ 4.4 (and possibly other compilers) it seems to write full brightness instead.

(See thread news://news.povray.org:119/4ba819f6@news.povray.org for examples.)

The proper solution should be to apply gamma correction after clipping.

When choosing PPM output with a bit depth other than 8 bits per color channel (e.g. +FP16), POV-Ray messes up the colors (see thread news://news.povray.org:119/4babb48f$1@news.povray.org)

When using cutaway_textures the differenced part traces black. Simple scene file attached.

The current Windows version of POV-Ray does not fully support forward slashes in pathnames; specifically, POV-Ray fails to recognize drive letters when followed by a forward slash, e.g. “C:/foo/bar.pov” or “C:/foo\bar.pov”, rejecting such names for e.g. Input_File_Name.

woodmaps.inc depends on colors.inc, more specifically the definition of the color “Clear” perhaps a #ifndef colors.inc belongs in woodmaps.inc or probably more correctly changing the call of “Clear” to rgbf 1

POV-Ray 3.7-generated JPEG image output files do not conform to the JFIF standard. Most importantly, the files written do not use the standard YCbCr color model (they seem to use plain RGB instead), nor do they have a proper JFIF tag.

As a consequence, some software may be unable to read the generated JPEG files properly. In addition, it seems that POV-Ray mixes up the Red and Blue channels.

I can no longer run a Myfile.ini over a network, on a different computer.

Possiblely related to:

    http://bugs.povray.org/task/97   FS#97  (Forward-slash pathnames not fully supported in Windows version)

-
Cannot open INI file
‘\\STEPHEN-POVRAY\Bishop3d\Objects\Industrial_enclosure\Telco_enclosure_extra.ini’.
Failed to start render: Failed to parse INI file

The following line in the lathe1a.pov, lathe1b.pov, and lathe1c.pov appears to have an error in it.

  <3.6.9>, <4, 1.1>, <3.4, 2>, <3, 1>, <2, 1>,

Although it works in version 3.6, only in 3.7 does a render time error ocurr.

Scene source should be adjusted to the following

  <3.6, 0.9>, <4, 1.1>, <3.4, 2>, <3, 1>, <2, 1>,

Automatic removal of user-specified bounding boxes cannot be disabled in current POV-Ray 3.7 betas; the Remove_Bounds ini file setting and the +/-UR command line option are silently ignored.

OpenEXR output currently writes an alpha channel when Output_Alpha=off (-UA), and does not write an alpha channel when Output_Alpha=on (+UA), i.e. doing it just the wrong way round.

When using “filter all VALUE” with an image_map using a 4-bit (16-color) paletted bmp image, debug builds of POV-Ray fail with an assertion.

According to code analysis, other paletted image formats with <256 palette entries are also likely to be affected; similar assertion fails can be expected when using the “filter INDEX, VALUE” feature on such files with an index exceeding the palette size. “transmit” shows the same flaws.

Request an #ELSEIF statement in POV SDL.

When right-clicking on a tab in the editor window a list of options should appear, such as:

* Close
* Close all but this
* Save
* Save as
* Print

See Notepad++, EditPad Lite, and Firefox for examples.

There already exist atan, atan2 and atan2d functions, why not atand?

value is erroneously clipped to the range 0..1 before being displayed

The text object isn’t working with /usr/share/fonts/truetype/freefont/FreeSans.ttf. Used to work - taken from an old .pov file of mine.

Rebuilt from
http://www.povray.org/redirect/www.povray.org/ftp/pub/povray/Official/Unix/povray-3.6.tar.bz2

$ povray +ifonttest.pov +ofonttest.png

Persistence of Vision™ Ray Tracer Version 3.6.1 (g++ 4.4.3 @
x86_64-unknown-linux-gnu)
This is an unofficial version compiled by:
darxus [at] chaosreignscom

.....

File: fonttest.pov Line: 8
Parse Warning: Character 101 (0×65) not found in /usr/share/fonts/truetype/freefont/FreeSans.ttf
File: fonttest.pov Line: 8
Parse Warning: Character 115 (0×73) not found in /usr/share/fonts/truetype/freefont/FreeSans.ttf

Verification that the problem is not in the .ttf file, this works (imagemagick):

convert -background lightblue -fill blue -pointsize 48 -font
/usr/share/fonts/truetype/freefont/FreeSans.ttf label:test fonttest.png

Problem verified when compiled from source on Ubuntu Lucid. Also exists in Ubuntu binaries from Lucid and Hardy.

Add metatags to output images identifying the file as having been created using POV-Ray.

If pretrace_start is set below pretrace_end, POV-Ray will run a high number of pretrace steps (without changing pretrace resolution).

polygon objects comprised of multiple “sub-polygons” don’t work properly if start/end points of sub-polygons do not exactly match, as can be demonstrated by the following code:

#default { texture { pigment { rgb 1 } finish { ambient 1.0} } }

camera {
  orthographic
  up 3.5*y
  right 3.5*x*image_width/image_height
  location  <0,0,-4>
  look_at   <0,0,0>
}

polygon { 8,
  // outer triangle
  0.70 * < cos(  0 *pi/180),sin(  0 *pi/180),0>
  0.70 * < cos(120 *pi/180),sin(120 *pi/180),0>
  0.70 * < cos(240 *pi/180),sin(240 *pi/180),0>
  0.70 * < cos(360 *pi/180),sin(360 *pi/180),0>

  // inner triangle
  0.35 * < cos(  0 *pi/180),sin(  0 *pi/180),0>
  0.35 * < cos(120 *pi/180),sin(120 *pi/180),0>
  0.35 * < cos(240 *pi/180),sin(240 *pi/180),0>
  0.35 * < cos(360 *pi/180),sin(360 *pi/180),0>
}

Note that the end points /should/ be identical. There are however some minor rounding differences, which mess up polygon computations. Compare with the following code, which leads to the desired results:

polygon { 8,
  // outer triangle
  0.70 * < cos(  0 *pi/180),sin(  0 *pi/180),0>
  0.70 * < cos(120 *pi/180),sin(120 *pi/180),0>
  0.70 * < cos(240 *pi/180),sin(240 *pi/180),0>
  0.70 * < cos(  0 *pi/180),sin(  0 *pi/180),0>

  // inner triangle
  0.35 * < cos(  0 *pi/180),sin(  0 *pi/180),0>
  0.35 * < cos(120 *pi/180),sin(120 *pi/180),0>
  0.35 * < cos(240 *pi/180),sin(240 *pi/180),0>
  0.35 * < cos(  0 *pi/180),sin(  0 *pi/180),0>
}

Code inspection shows that the polygon insideness testing code tests for precise equality of the points, whereas the general policy of POV-Ray is to accept slight rounding differences.

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.

Adjusting the brightness of an image-mapped sky sphere, although not an uncommon task especially when using HDR light probes, currently is cumbersome at best, as it is not possible to specify a “finish { ambient ... }” statement.

To simplify tuning a sky sphere’s brightness, I suggest introducing a “brightness FLOAT” modifier (defaulting to 1.0) to either the sky_sphere block or (as a more versatile solution) the image_map statement.

It seems that the new area_illuminate flag for area lights does not take into account fade_power and fade_distance. The illumination falloff is still being calculated from the center of the light_source.

Here’s some relevant code:

camera{
  location<0,10,-10>
  look_at 0
}
plane{y,0 pigment{rgb 1}}
light_source{
  y*.1,100
  area_light x*10, z*1, 8, 8
  jitter
  area_illumination
  fade_power 2 fade_distance 1
}

A df3 file is written, with header 00 00 00 00 00 00 and no data (hypothetically valid df3 file).
This file is used as density file for media, using interpolation. This causes a crash once Pov-Ray starts rendering the pixels that contain media.
All pixels rendered before that render fine. Using no interpolation does not cause a crash.

Sample Scene:
#fopen out “random.df3” write
#write (out, uint16be <0,0,0>)
#fclose out

box{0,1 pigment{rgbt 1} hollow interior{media{
density{density_file df3 “random.df3” interpolate 1}}}} // interpolate 2 also crashes, interpolate 0 does not.

System: Win7 x64, 3.7 Beta 38

Hi,

I have a problem with photons. The following stripped down code simulates a
slide projector:

#include "colors.inc"

global_settings {
  #if (1)   // switch photons on/off
    photons { count 1000000 }
  #end
}

camera { location <0, 0, 200> sky<0,1,0> look_at <0,200,-200> angle 90 }

// projection screen
plane { z, -200 texture { pigment { White } finish{ diffuse 1 ambient 0.1} } }

// slide
polygon {
  5, <0,0,0>, <1,0,0>,<1,1,0>,<0,1,0>,<0,0,0>
  pigment { image_map {jpeg "s7_0.9_320.jpg" interpolate 2 filter all 1.0 } }
  translate <-0.5, 0.2, -0.3>
  photons { target refraction on reflection off collect off }
}

// projector lamp
light_source { <0, 0, 0>  color <1,1,1> }

——————————————-

A point light source projects through a image_map onto a screen.

Without photons the projected image is ok:
http://img838.imageshack.us/i/test4woph.png/

With photons the left and right bottom corners of the image will be clipped:
http://img101.imageshack.us/i/test4wph.png/

The size of clipped corners depends on the y-offset in the translate command.

The povray Version is:
Persistence of Vision™ Ray Tracer Version 3.6.1 (Debian (x86_64-linux-gnu-g+
+ 4.3.3 @ x86_64-pc-linux-gnu))
(the 3.7 beta has the same problem)

I posted this question in the general news group and got an answer by Christian Froeschlin,
who could reproduce the problem and suggested as workaround to divide the slide into small stripes

http://news.povray.org/povray.general/thread/%3Cweb.4c972bdffcc128eac947b6de0%40news.povray.org%3E/

This works, but doesn’t explain the problem.

Does anyone have an idea, whats wrong?

Many thanks,
Corvin

I used POV-Ray to make an animation of my Morgan driving around a slalom course. (If you are curious, you can see the output on youtube under my user name, nojonushi.) To make the long swooping fenders I used Mike William’s SweepSpline macro.

The code rendered the 1189 frames in one go with no problems. But the wheels in that animation do not rotate, so I then added code to rotate the wheels. In the calculations I added I used a #while loop to step through the spline containing the route coordinates and total up the distance traveled. Running POV-Ray on this file produced a random number of images and then issued an error, e.g.

 0:00:00 Processing Frame 456 of 1189
 0:00:00 Parsing

File: mogslalom.pov Line: 1918
Parse Warning: Patch objects not allowed in intersection.
File: mogslalom.pov Line: 2988
File Context (5 lines):

                object {
                SweepSpline(TFSpline,

Parse Error: Identifier expected, incomplete function call or spline call found instead.

Most of the parameters for the macro are missing. But this is after successfully generating, in this case, 455 images.

I have attached a text file with set-up and sample code that has given the error on two different machines.

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

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.

The documentation says:

“-J Sets aa-jitter off”

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

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.

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)

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.

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

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.

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

In POV-ray 3.7 beta 33 under Windows XP, the editor’s MRU list incorrectly handles files that have a comma in the pathname. Only the part of the name before the comma appears on the MRU list, but the rest of the name is left off.
Consequently, the file cannot be reopened via the MRU list. The file is also not reopened on launch if pov was closed with the file open. This also occurs in 3.6.1, I haven’t tried it under 3.6.2 yet.

Interestingly enough, a quick peek in the registry shows that both 3.6 and 3.7
are saving the entire path name correctly under HKEY_CURRENT_USER\Software\POV-Ray\v3.6\POV-Edit\Recent (or \v3.7\POV-Edit\Recent).

This seems to be limited strictly to the editor’s MRU list. The file can still be opened normally using the open dialog box. Calling POV-ray from the command line and using a file or path name with commas in it works correctly. Included files with commas in the path work correctly, and the Tools→Edit last rendered file/View last rendered file work correctly also.

To duplicate, save a file with a comma in the pathname (either in the directory
name or the filename itself). Close the file, then attempt to reopen it using the MRU list in the file menu.