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

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.

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 -H10 -W20 myscene.pov’ will generate a file with a picture 10 pixels high and 20 pixels wide, BUT in the message pane it displays

Image resolution.....20 by 10 (rows 1 to 20, columns 1 to 10)

instead of

Image resolution.....20 by 10 (rows 1 to 10, columns 1 to 20)

or

Image resolution.....20 by 10 (columns 1 to 20, rows 1 to 10) 

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.

unixoptions.cpp has a getenv(”HOME”) that does an assignment without checking to see if getenv returns NULL.

This causes an immediate and unceremonious segfault in those situations where $HOME is not set such as in the case where povray is launched by a daemon.

Best solution might be to set the home to /tmp and print a warning message about $HOME not being set.

FileBackedPixelContainer uses a FILE* to manage the backing store and under Linux/Unix defines fseek64 to be a kind of incantation of lseek64.

Since fseek64 and fseek64 have return values that are logical opposites this causes an exception to be thrown.

Moreover since the buffer size on a FILE is quite a bit smaller than a line of pixels (in terms of bytes), mostly what’s being done in this function is a lot of sloshing of bytes that don’t do much... which is to say that the intended caching mechanism is getting a very low hit rate now that povray is working in 32×32 pixel per-thread chunks.

The cache miss problem and the volume of bytes read/written grows exponentially as the size of the image grows.

Attached is a replacement function that seems to be working well and should produce a performance increase even under Windows. I originally went with simply fixing the fseek/lseek problem but saw a 10% decrease in render time on 2048×1024-sized images when I made the cache target smaller.

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

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.

I/O Restriction defaults are not being properly set on a fresh install of POVWIN.

See this thread for more information.

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/

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.

20 library paths is a bit small given the sheer number of include files I’ve collected over the years. An increase in the number, and/or the ability to include wildcards in the search path, would be great.

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.

Request a system variable to test whether a scene file has been included by another scene file.

For instance:

#if (is_included)
  camera {...}
#end

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