POV-Ray

When rendering a series of scenes (e.g. animation, or render queue in POV-Ray for Windows), number_of_waves is not properly reset to its default value between scenes, causing the parameter to default to the value set by the previous scene.

For instance, rendering the following scenes from a queue will cause “arches.pov” to be rendered differently the second time:

1. scenes\textures\finishes\arches.pov
2. scenes\textures\normals\normavg.pov
3. scenes\textures\finishes\arches.pov (again!)

The parser does not accept mesh objects (or CSG objects including a mesh object) as a parameter to the inside() built-in function, reporting error “Solid object identifier expected”, even if the mesh is “solidified” by specifying an inside_vector.

(see news://news.povray.org:119/4a983716@news.povray.org)

Add a way to get and set font metrics.

Attached an image that shows what I’m talking about.

Thanks!!

Improve native support for 2D primitives. Ideally a 1:1 mapping of SVG primitives/shapes. They go a long way to making diagrams look a lot better. Having to create image maps based on externally created bitmaps slows the workflow down a lot!

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

In POV-Ray 3.6 (including 3.62), checker and cells patterns are off by 0.001 (1e-3) units, as can be demonstrated with this scene:

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

box { <-1,-1,0>, <0,0,1> pigment { checker color rgb 1 color rgb 0 scale   0.2 translate <-0.5,-0.5,0> } finish { ambient 1 diffuse 0 } }
box { < 1, 1,0>, <0,0,1> pigment { checker color rgb 1 color rgb 0 scale   0.2 translate < 0.5, 0.5,0> } finish { ambient 1 diffuse 0 } }
box { < 1,-1,0>, <0,0,1> pigment { checker color rgb 1 color rgb 0 scale 200.0 translate < 0.5,-0.5,0> } finish { ambient 1 diffuse 0 } }
box { <-1, 1,0>, <0,0,1> pigment { checker color rgb 1 color rgb 0 scale 200.0 translate <-0.5, 0.5,0> } finish { ambient 1 diffuse 0 } }

The same can be demonstrated for the cells pattern.

POV-Ray 3.7 beta 34 is “clean”.

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

The configure script for unix uses a dumb string compare to test whether libpng version is 1.2.5 or higher, leading it to reject (for instance) libpng 1.2.27 and unnecessarily compile and statically link the older libpng version it comes with.

Scenes starting with the incorrect syntax

version 3.7;

do not raise an error, instead they render a black screen with an empty scene warning.
#version should fail with an error when the # is missing.

Windows 7, Home Premium 64bit
In Options/Editor Window/Editor Preferences/Language Tabs
saving a tab size of 4 does not work - on restart it reverts to the default of 8

In Options/Editor Window/Editor Preferences/Misc
saving a Line numbering style of Decimal and a Start number of 1, does not work, on restart the defaults are restored.

When I try to re-render the insert menu bitmaps,on the Windows version 3.7b36 there is an error with the
Shapes.pov file.
line 474: Parse Error: Unexpected additional ‘.’ in floating-point number

line 474 is:

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

The second vector has two decimal points
Change to <3.6,.9>

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)

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.

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

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

The #switch directive isn’t parsing correctly. In the following construct NO warning or error is generated:

#switch (RF)

case (0)
	rotate z*355
#break
case (144)
	rotate z*7.5
#break
case (216)
	rotate z*5
#break

#end

RF is a variable passed to the macro in which this construct resides. The first ‘case’ action IS executed, but none of the others are on successive calls to the macro. If I properly add ‘#’ to the second case the 1st and 2nd condition are executed but not the last. If ‘#’ is REMOVED from any of the break directives an error is generated and parsing halts.

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.

POV-Ray 3.7 does not show output options, such as:

Output Options
  Image resolution 640 by 480 (rows 1 to 480, columns 1 to 640).
  Output file: D:\foo\test.png, 24 bpp PNG
  Graphic display......On  (gamma: 2.2)
  Mosaic preview.......Off
  CPU usage histogram..Off
  Continued trace......Off

(the above is what 3.6 used to show)

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.

Mosaic preview display didn’t work as expected, given these command line options: +sp64 +ep16. The preview was solid colored instead of the coarse preview that you’d expect.

I’ve tested a fix to unix/disp_sdl.cpp from clipka and it appears to work.

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.

The included scenes\advanced\benchmark.pov (v1.02)is different then the winpov menu render\run benchmark (v2.01).

The winpov menu render\run benchmark is missing some objects, turned off in early betas?

There should be a table of contents on each page of the documentation, or at least on the very long pages. Scrolling through the entire page to figure out what topics are covered sucks.

Assuming there are no performance issues, it would be nice to tell Povray to select the pixels to render randomly, so that the image gets filled in gradually instead of from top to bottom and from left to right.

Also, maybe an option to tell it to render every Nth pixel.

Request an #ELSEIF statement in POV SDL.

Request #BREAK statement inside #WHILE and #FOR loops.

In POV SDL it can sometimes be ambiguous what exactly a macro returns. An explicit #RETURNS statement would make this unambiguous.

Currently, arrays may contain only one object type. Would be nice to eliminate this restriction and allow arrays to contain objects of different types.

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.