POV-Ray

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

The version 3.6 documentation needs to be updated to suit the changes for version 3.7.

Versions of POV-Ray prior to 3.7 had the ability to write the image output as a stream to STDOUT. This was particularly useful in unix as it allowed POV-Ray output to be directly piped to other processes.

The introduction of SMP and the associated non-linear generation of pixels complicates stream output to the extent that it is not currently available in v3.7.

At a minimum 3.7 must at least be able to write the completed image to STDOUT after a render - this is not an optimal solution but is better than nothing. Ideally however once entire lines are complete (most likely this will occur in batches due to the block nature of the render subdivision) these lines will be written immediately to STDOUT (after possibly being processed through the appropriate image format routines).

NB currently the image format routines are not invoked until the entire render is completed, so to do this would be a significant modification. However if we limit real-time stream output to “simple” non-compressed formats (e.g. PPM), it would not be overly difficult, and from the point of view of Unix-like operating systems (where the piping feature is most useful), if the data is in PPM format it can easily be transformed into anything else.

Recruit version 3.7 documentation editors from the users community.

no warning is issued when an object/primitive has no pigment type given

Subsurface scattering must be made radiosity-aware.

Develop MediWiki extension to extract documentation sets from the POV-Wiki.

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
}

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)

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?

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

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.

In the folder “ready made scenes”, there is the file “B0 - Basic scene 11 - pure white background.txt”.
The text string to be rendered lacks the “e” in “pure”. Unfortunately, this makes the typo visible in the “Insert menu” preview image.

If the “e” is added, the text needs to be scaled a bit smaller (0.43 instead of 0.44) to fit inside the view.

The following code contains a possible “fix” (whatever).
It would be great if someone could fix this easy issue:

text { ttf "arial.ttf", "pure white background", 0.02, 0.0 // thickness, offset
       texture{ pigment{ color rgb<1,0.6,0>*0.5 } 
                finish { phong 0.1 }
              } // end of texture

       scale<1,1.25,1>*0.43
       translate<-2.10,-0.30,0.00 >
      } // end of text object ---------------------------------------------

I’ve been trying to upgrade povray 3.6.1 to 3.7-beta-32. I’ve configured with no additional arguments, and the configure dies with:

checking whether to build the boost thread library from sources... no
checking for boostlib >= 1.35... yes
checking whether the Boost::Thread library is available... yes
checking for exit in -lboost_thread... no
checking for exit in -lboost_thread-boost_thread... no
configure: error: Could not link against boost_thread-boost_thread !

I figured that the problem was with my boost installation (1.35) and upgraded boost to 1.39; the problem remains. I tried to see if exit was defined in libboost_thread and/or libboost_thread-boost_thread and it isn’t. Just to be sure that my currrent setup works for the released version, I rebuilt/reninstalled 3.6.1, which went without problem.

I’m on a slackware-12.2 box, using gcc-4.4.0.

Hi,

following scene will not be rendered correctly in 3.7.beta.35a:

http://lib.povray.org/collection/beamtest/cousin%20ricky%201.1/beamtest.html

maybe it is a configuration problem or it is a real bug.

How to do it: (with raddem.ini & raddem.pov from distributed scenes, copied in local directory)

1. run “povray raddem.ini” until frame 6 or more (irrelevant, at least frame 1 & 2 are needed), interrupt the render.
2. restart “povray raddem.ini +C”

It fails at frame 2 with
Possible Parse Error: Cannot find file ‘raddem.pov’, even after trying to append
file type extension.
Parse Error: Cannot open input file.
Fatal error in parser: Cannot parse input.
Render failed

The detection of frame 1 is fine.

Consider the following script:

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

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

  Blah

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

(This happens as of beta 34)

The following scene will cause POV-Ray to allocate memory until all available memory is used, resulting in an Out of Memory error message:

#declare n1 = normal
{
    crackle .5
    scale 0.001
    accuracy 0.0001
}

#declare n2 = normal
{
    bumps 0
}

camera
{
    location <0, 0.2, -1>
    look_at <0.4, 0.3, 1>

    focal_point <0.4, 0.3-.0, 1>
    blur_samples 25
    confidence .9
    variance 0
    aperture .05
}

light_source
{
    <-10, 10,-5>, rgb 1.5
    area_light x*2,y*2,7,7 orient adaptive 2
}

sphere{ <0, 0, 0>, 0.5 pigment {color rgbf <0.85,1,.95,1>}

    interior
    {
        ior 1.5
        fade_color rgb <0.0, 0.5, 0.0>
        fade_power 2
        fade_distance 10.5
        dispersion 1.1
        dispersion_samples 100
    }

    normal {

        checker normal{n2} normal{n1}
        scale 0.1
        warp { spherical }

    }

    translate z*1
} 

Hello,

when I use an image_map within a pigment_map (for example only a half of a box gets the image_map), the image_map is not rendered correctly.

For example when I have this box (scene and images are attached)

box {
	0, 1
	pigment {
		gradient z
		pigment_map {
			[0.4 image_map { png "test.png" } ]
			[0.4 color Cyan ]
		}
	}
}

So on the front you should see the image of test.png (in the attached scene it’s just red).
But on some pixels of the front you see the cyan color of the distant half of the cube.

Rendering the scene mutliple times produces the same result.

Rendering the scene at 200×150 is sufficiant.

povray +W200 +H150 scene.pov

I tested it with 3.6.1 and 3.7.0 beta 32 on Linux

The following SDL code

sphere {0, 1 pigment {image_map {png "missing.png"}}

yields “render failed” in 3.7b25 and the position of the error
is not highlighted in source code, giving no clue what went wrong.
In 3.6 this yields “Parse Error: Cannot open PNG file”.

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.

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

In POV-Ray’s documentation it says:

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

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

Max_Image_Buffer_Memory = 3096

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

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

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

I tested both under Windows XP and Debian 6.0.5.

The following editor issue experienced in 3.7 RC 6 under Win7/64::

Place the curser at the middle of a row.
Press enter. Now the line has been split and the cursor is at the beginning of the new line, followed by the rest of the original line
Press backspace.
Instead of restoring the original line, the second part of the line disappears.

RC 3 under Vista/32 (and earlier versions) behave normally.

This is an annoying little bug in the Windows GUI:

Installed 3.7 RC07 on Windows 8.
No previous povray installation on this machine.

How to reproduce error :

- Open a file in the editor.

- Right click on the files tab. This opens a popup menu showing “Open containing folder/Copy file to clipboard/....”.

-Now each selection in this menu does open the containing Folder. I cannot close or run any of the other actions in this menu.

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

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

Some sample scenes are no longer up-to-date, causing warnings, and should be fixed. For instance, the advanced/benchmark scene still includes “Buffer_Output=Off” and “Buffer_Size=0” in its .ini file. This should be checked systematically, and fixed as appropriate.

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