POV-Ray

There are various scripts around the Net meant for approximating things like isosurfaces and parametric objects using meshes. It would probably run bit faster and be easier to use if this were supported natively within Povray. The feature would require an additional object parameter in order to toggle this behavior on/off.

It would be nice to configure an INI option to add render information like render time, date, and input file to output images.

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?

Would be nice to have a “Delete” option in the File menu to delete the current file from disk.

The documentation assumes that INI files (as well as the command line!) are parsed and processed instantly. This no longer holds true for POV-Ray 3.7, where parsing INI files (and the command line) and processing it are separate operations that occur at different times. As such, one consequence is that INI file options only take effect after reading the whole INI file, and possibly later.

As such, documentation statements such as <http://www.povray.org/documentation/view/3.6.1/222/>
“Note: that these options take effect immediately when specified. Obviously any error or warning messages that might occur before the option is read will not be affected.”

Are no longer correct. It needs to be explained that options only take effect after the INI file has been read. An error in the INi file causes other options _not_ to take effect because reading of the INi file is aborted prematurely.

The ability to specify an exact name for output images during animations would be great. As it is, POV-Ray appends a numerical designation to each image (e.g. image001.png, image002.png, etc. Overriding this behavior would allow certain tasks to be accomplished without cluttering the hard drive. For instance, an image could be rendered over and over again. Certain things like cellular automata, ripple tank simulations and feedback fractals could be performed without the resulting long list of images in a given directory.

The command line option could be in the form of +oefile/+Output_File_Name_Exact=file or some such.

Macros are finicky about how you type your code. What works outside macros sometimes fails inside them. For more information see the threads:

“Problems with macro (3.6)”, in p.a-u, 06-09-10
“Bad operands”, in p.g, 05-20-10

Still not sure *what* exactly the problem was, but one of my workarounds ended up working.

In POV 3.6 you could set the Statistic_File option to a custom file and folder path. In the beta I get an “Cannot open file” error. Has the feature been intentionally removed or did it become broken?

The documentation entries for shapes.inc, shapes_old.inc, shapes2.inc, shapesq.inc, etc. should have thumbnails next to the object descriptions.

In the tray icon, I’d like to see the render progress indicated somehow icon itself. Either a set of numbers (percents), or a change in color of the icon (e.g. from top to bottom). Something like the attached images.

Windows allows you to associate programs with file extensions using the “Open with” file manager right-click menu extension.

I’m running Windows 7 64bit, and installed the 64 bit versions of 3.6.2 and the beta appropriately.

A couple of problems that I haven’t tested very thoroughly:

1. If you have both POV 3.6.2 and the beta installed at the same time, you can no longer using this dialog change the association to the beta once it has been created for 3.6.2. There’s no error or anything; it just opens the file inside 3.6.2 instead. Maybe because both versions appear as “POV-Ray for Windows” to this dialog? Would adding the version number to the name fix things? Anything I can do on my end of things to resolve this?

2. In POV-Ray 3.6.2, I can use this dialog to open *.inc, *.txt and other files in POV-Ray, but only if POV-Ray isn’t already running. If POV-Ray is already running I get an “Only /EDIT and /RENDER may be passed to previous instance” error. Files with the *.pov extension open properly regardless, without any error. I am unable to test this in the beta at the moment due to the first problem unfortunately. Could someone please test this with the beta and confirm whether the behavior also exists?

3. With the POV-Ray 3.7 beta, entering the following command in the command prompt results in the same error:

   "C:\Program Files\POV-Ray for Windows v3.7\bin\pvengine64.exe" "D:\Working\Povray\GearHead\LoadingScreen\btr_maanji.pov"

If I change it to the following it works however:

   "C:\Program Files\POV-Ray for Windows v3.7\bin\pvengine64.exe" /EDIT "D:\Working\Povray\GearHead\LoadingScreen\btr_maanji.pov"

Is this error/behavior really necessary? Would it be OK to instead change the behavior when the /EDIT flag is omitted in the
command-line such that the file is opened in the editor by default, without throwing an error?

Currently, cameras placed inside object or union statements will halt the render with an error. Take for instance the following case:

#local temp_camera_1 = camera
{
  orthographic
  location  z*-12
  direction  z
  up    y
  right    x*image_width/image_height
  scale    32
}

#local temp_light_1 = light_source
{
  0
  color rgb 1
  translate <-30, 30, -30>
}

#local temp_light_2 = light_source
{
  0
  color rgb 1
  translate <-30, 30, +30>
}

union
{
  object {temp_light_1}
  object {temp_light_2}
//  camera {temp_camera_1}  // doesn't work!!!
}

//object {temp_camera_1}  // doesn't work!!!
camera {temp_camera_1}  // works!!!

Changing this behavior would make it possible to more easily apply transformations to scene objects and the camera at the same time in situations where the scene’s frame of reference is in motion relative to the rest of the scene, for instance in animations.

clipka anonymous@anonymous.org wrote:
> Am 29.06.2010 04:27, schrieb jberry02:
>
> > First, note that this is the Windows version.
> > Second the issue is not with opening the ini file, but with opening the scene
> > file from within the ini file.
> >
> > I have a scene.ini file, that has a line:
> >
> > Input_File_Name=scene
> >
> > under POV-Ray 3.5 *and* POV-Ray 3.6, the scene defined in the file scene.pov is
> > rendered properly using the parameters specified in the scene.ini file. The ini
> > file is opened from the POV-Ray GUI, and run using the “Run” button.
> >
> > under POV-Ray 3.7, I get an error - I originally thought that it was simply not
> > looking for scene.pov (i.e., it wasn’t adding the .pov extension when trying to
> > open the scene file), but looking closer the error is *actually*:
> >
> > Input file ‘C:\[...]\scene’ not found; cannot determine I/O permission for
> > write.
> > Failed to start render: Cannot open file.
> >
> > In other words, it appears that the problem is that it isn’t adding the default
> > ..pov extension when it is trying to do the I/O permission check. I do not have
> > any special I/O permisssions configured for any version of POV-Ray (I get the
> > pop-up dialogs), and this is a change in behavior from 3.6 to the current beta
> > of 3.7. The scene.pov file is not in any of the POV-Ray directories - it is in
> > a separate tree where I keep my scene files.
>
> Having looked at it in a debugger, I can confirm that there is a
> problem, and that you don’t seem to be far off the mark:
>
> The error occurs when POV-Ray tries to determine the I/O permissions for
> the /output/ file. If that isn’t explicitly specified with a path,
> POV-Ray will try to get the path from the input file; however, it will
> take the unprocessed parameter (in the sample case “scene”) rather than
> the file name POV-Ray makes of it (”scene.pov”), and then attempts to
> get the full /long/ path name of the file (remember the good old 8.3
> filenames for compatibility with 16-bit programs?), which only works
> when the file exists.
>
> Would you mind submitting a bug report to <http://bugs.povray.org>?

Installation script (from sources) when run with a classical “sudo make install” would create povray.ini & povray.conf in $HOME/.povray/3.7 (so far so fine) with the owner as root and the permission to readonly for the real user.

Same goes for the owner of the 3.7 directories tree : .povray & .povray/3.7 are created with root owner, despite being in $HOME of the performing user.

Please fix ?

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

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

Test bug for checking features of flyspray.

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.

I’d like to request the ability to create a date/time stamp on output images so that new renders don’t always overwrite old ones. Thanks.

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

the quick_color feature doesn’t work when +qN or Quality=N is set to 5 or below

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.

Currently, output image is buffered using POV-Ray’s RGBFT color model and floating point values, leading to a memory consumption of 20 bit per pixel. This is an unproportionally large memory footprint, given that the only further processing performed on the buffered data is conversion of the data to the desired output file format, which will typically use only 3 bytes per pixel (at most 12 bit per pixel).

The situation can be improved by choosing the output image buffer container based on the desired output file format and parameters. To this end, the following code changes should be made:

• Bundle image file format handler code into classes (typically one per file format)
• Include a method to determine the best data container type for the image buffer
• Instantiate the desired image file format handler object prior to rendering, querying the handler object for an image buffer

In addition to picking a suitable image data container from the already existing palette, careful design might also allow to use custom containers to directly pass the data to a library (in case the library provides its own buffering anyway), or write it directly to the output file (e.g. when writing image data to stdout). To make this compatible with multithreaded rendering, the following changes would have to be made:

• Add code to detect when a row of SMP blocks has been finished, and call a certain method on the image handler object
• Design the custom containers in such a way that they can buffer any number of unfinished SMP block rows as needed

Bounding box computation for CSG intersection appears to be broken when one member is an arbitrarily transformed plane.

// +W640 +H480 +MB1

#include "transforms.inc"

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

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

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

plane {
  y, -1
  pigment { color rgb <0.7,0.5,0.3> }
}

intersection {
  sphere {
    0.0, 1 }
  plane { -x, 0 transform { Shear_Trans(x,y+x*0.3,z) } }
  texture {
    pigment {
      radial
      frequency 8
      color_map {
        [0.00 color rgb <1.0,0.4,0.2> ]
        [0.33 color rgb <0.2,0.4,1.0> ]
        [0.66 color rgb <0.4,1.0,0.2> ]
        [1.00 color rgb <1.0,0.4,0.2> ]
      }
    }
    finish{
      specular 0.6
    }
  }
  rotate -y*5
}

In some cases it may be desirable to run POV-Ray from a batch file, without causing it to “steal the focus”.

I suggest making this dependant on whether POV-Ray is run with the /EXIT parameter.

Tested with beta 40. Also affect version 3.6.1 as reported in the discution group.

When using radiosity and emissive media. Any object, or part of, that is inside the media container is not affected by the illumination comming from the media.

When using scattering media, the light scattered by the media also don’t affect objects that are inside it’s container.

http://news.povray.org/povray.newusers/thread/%3C4cf8fe22%241%40news.povray.org%3E/

At the moment in the Poly Object the maximum power is 15. The mathematics for converting the three parametric equations for x, y and z into a formula for the Poly Object require that the equations are squared several times given max-powers of 4, 8 and even 16. I’ve one eqaution that needs power 16. At the moment this is just one power short. Please raise this to 16. That’s all I ask for.

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.

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)

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.

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.

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

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.

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

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