POV-Ray

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.

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

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.

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.

There is a confirmed bug when writing jpg file format with the current linux build (beta39). when specifying +fj output format the following error occurs:

JPEG parameter struct mismatch: library thinks size is 372, caller
expects 376
JPEG parameter struct mismatch: library thinks size is 372, caller
expects 376
Render failed

this has been confirmed on ubuntu 10.4 and openSuSe 11.2 (assuming 32 bit version) as openSuSe 11.2 64-bit reports no problem

there has been a proposed fix to ~smp/source/base/image/jpeg.cpp that appears to work, however it requires some additional work to make it a platform (linux) and compiler (gcc) specific fix.

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

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

Include file golds.inc still provides warnings when parsed, a shame for a standard include file.
(colors.inc is ok, I did not test the other includes)

File '/usr/local/share/povray-3.7/include/golds.inc' line 118: Parse Warning:
 Expected pure RGB color expression, unexpected filter and transmit components
 will have no effect.
File '/usr/local/share/povray-3.7/include/golds.inc' line 119: Parse Warning:
 Expected pure RGB color expression, unexpected filter and transmit components
 will have no effect.
File '/usr/local/share/povray-3.7/include/golds.inc' line 129: Parse Warning:
 Expected pure RGB color expression, unexpected filter and transmit components
 will have no effect.
File '/usr/local/share/povray-3.7/include/golds.inc' line 130: Parse Warning:
 Expected pure RGB color expression, unexpected filter and transmit components
 will have no effect.
File '/usr/local/share/povray-3.7/include/golds.inc' line 140: Parse Warning:
 Expected pure RGB color expression, unexpected filter and transmit components
 will have no effect.
File '/usr/local/share/povray-3.7/include/golds.inc' line 141: Parse Warning:
 Expected pure RGB color expression, unexpected filter and transmit components
 will have no effect.
File '/usr/local/share/povray-3.7/include/golds.inc' line 151: Parse Warning:
 Expected pure RGB color expression, unexpected filter and transmit components
 will have no effect.
File '/usr/local/share/povray-3.7/include/golds.inc' line 152: Parse Warning:
 Expected pure RGB color expression, unexpected filter and transmit components
 will have no effect.
File '/usr/local/share/povray-3.7/include/golds.inc' line 162: Parse Warning:
 Expected pure RGB color expression, unexpected filter and transmit components
 will have no effect.
File '/usr/local/share/povray-3.7/include/golds.inc' line 163: Parse Warning:
 Expected pure RGB color expression, unexpected filter and transmit components
 will have no effect.

Included math.inc into scene and recieved this fatal error from povray:

File '/usr/local/share/povray-3.7/include/math.inc' line 248: Parse Error: Expected 'string expression', float function 'vlength' found instead

Appropriate place in math.inc:

245 > #end
246 >
247 > // Distance between V1 and V2
248 > #macro VDist(V1, V2) vlength(V1 - V2) #end
249 >
250 > // Returns a vector perpendicular to V

Running newly-downloaded/newly-compiled POV-Ray 3.7.0, on Linux x86_64 system

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

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.

see my post titled: “area light and radiosity problem?” in povray.binary.images [Edit - copied that post’s text here - clipka]

wondering about what’s going on here with this series of images. the radiosity and area light settings are unchanged from image to image, and all I did was radiosity on/off and area_light on/off (btw: using rad_def “Normal” settings)

the 1st image is radiosity only, the 2nd is area light only, and the 3rd combines them:

what’s up with blotches? change #5819/5820 (octree) or maybe something still with area lights?

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
}

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

Compiling the sources with clang instead of g++ (on ubuntu 12.10 with boost 1.50)

./configure COMPILED_BY=”your name here <also@email>” LIBS=-lboost_system –disable-io-restrictions CC=clang CXX=clang

there is a few warnings that catch the eyes (and other as well that I dismiss so far, such as cases not covered in switch and empty body in if, or extraneous parentheses in tests):

support/randomsequences.cpp:553:15: warning: field is uninitialized when used here [-Wuninitialized]
                        startIndex(startIndex)
                                   ^
support/randomsequences.cpp:553:15: warning: field is uninitialized when used here [-Wuninitialized]
support/randomsequences.cpp:974:40: note: in instantiation of member function 'pov::PrecomputedNumberGenerator<int>::PrecomputedNumberGenerator' requested here
        SeedableIntGeneratorPtr generator(new PrecomputedIntGenerator(factory, count));
                                              ^
support/randomsequences.cpp:553:15: warning: field is uninitialized when used here [-Wuninitialized]
                        startIndex(startIndex)
                                   ^
support/randomsequences.cpp:984:43: note: in instantiation of member function 'pov::PrecomputedNumberGenerator<double>::PrecomputedNumberGenerator' requested here
        SeedableDoubleGeneratorPtr generator(new PrecomputedDoubleGenerator(factory, count));
                                                 ^
support/randomsequences.cpp:553:15: warning: field is uninitialized when used here [-Wuninitialized]
                        startIndex(startIndex)
                                   ^
support/randomsequences.cpp:1011:43: note: in instantiation of member function 'pov::PrecomputedNumberGenerator<pov::Vector3d>::PrecomputedNumberGenerator' requested here
                return SequentialVectorGeneratorPtr(new PrecomputedVectorGenerator(factory, count));
                                                        ^
support/randomsequences.cpp:553:15: warning: field is uninitialized when used here [-Wuninitialized]
                        startIndex(startIndex)
                                   ^
support/randomsequences.cpp:1056:45: note: in instantiation of member function 'pov::PrecomputedNumberGenerator<pov::Vector2d>::PrecomputedNumberGenerator' requested here
                return SequentialVector2dGeneratorPtr(new PrecomputedVector2dGenerator(factory, count));

Self referencing member in creator does not seems to be great for a reproducible pseudorandom generator (some compiler/architecture might force to 0, other might not... seems bad karma).

                           
             povmscpp.cpp:1875:4: warning: delete called on 'POVMS_MessageReceiver::HandlerOO' that is abstract but has non-virtual destructor [-Wdelete-non-virtual-dtor]
                        delete nodeptr->handleroo;
                        ^
povmscpp.cpp:1877:4: warning: delete called on 'POVMS_MessageReceiver::Handler' that is abstract but has non-virtual destructor [-Wdelete-non-virtual-dtor]
                        delete nodeptr->handler;
                        ^

Maybe just a missing keyword (virtual) in the header file ? Or is it harder ?

shelloutprocessing.cpp:260:28: warning: expression result unused [-Wunused-value]
        for (s = str.c_str(); *s; *s++)
                                  ^~~~

Why “*s++” ? why not just “s++” ?

renderfrontend.cpp:1165:57: warning: trigraph ignored [-Wtrigraphs]
                                        default:                                    t = "(???)";                            break;
 

I guess it’s not an intended trigraph. Might nevertheless perturb some compiler/result.

When using the ‘background’ directive with a transparent color, for example:

  background { color rgbt <0, 0, 0, 1> }

the final image is still opaque (both the one displayed in the render window and the PNG actually saved to disk).

Expected behaviour is for it to be transparent.

The parser is failing to read the .tiff file extension from the input string...

bump_map { tiff "earth03_hf2.tiff" }

Results in file not found, but

bump_map { tiff "earth03_hf2" }

will find the file. It might be that it’s not a three character extension?

Suggestion:

In file screen.inc, have macro Screen_Object() set no_radiosity on the object.

After a long parse period and a relatively quick rendering, POVray gets stuck at 99% when rendering the attached file.

Rendered at 6144x3072px with antialiasing set to 0.3.

Can anyone confirm?

When aborting a render when there are unfinished blocks among finished ones, under certain conditions some of those blocks are skipped when continuing the render later.

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.

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.

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.

While testing if the png support was working, I tried 3.7.0rc3 on NetBSD-5.99.45/amd64, and had the following problems:

1. lseek64 (used in source/base/image/image.cpp) is not portable, and not necessary on NetBSD (off_t there is large-file-safe)
2. unix/Makefile.am doesn’t add -lboost_thread to povray_LDADD, which breaks linking the executable.
3. vfe/unix/platformbase.cpp uses CLOCK_THREAD_CPUTIME_ID, which is not provided on NetBSD (I hacked around it by defining the symbol to “0”, but that’s of course not a correct fix).
4. vfe/unix/platformbase.cpp uses CLOCK_PROCESS_CPUTIME_ID, which is not provided on NetBSD – it’s called CLOCK_REALTIME like on FreeBSD, so we could just add defined(NetBSD) to the FreeBSD case, except for point 3.
5. vfe/unix/vfeplatform.cpp uses WEXITSTATUS. For this, sys/wait.h should be included. The obvious fix is
#ifdef HAVE_SYS_WAIT_H
# include <sys/wait.h>
#endif
but this also needs a check in the configure script.

Fixing all this, I get it to build, but core dump when run against the demo file from http://www.csb.yale.edu/userguides/graphics/povray/demo.pov.html.
Backtrace is
Program terminated with signal 11, Segmentation fault.
#0 0x00000000004ac479 in boost::gregorian::date::date ()
(gdb) bt
#0 0x00000000004ac479 in boost::gregorian::date::date ()
#1 0x00000000004d29f7 in boost::gregorian::date::date ()
#2 0x0000000000479a85 in std::vector<std::string, std::allocator<std::string> >::operator= ()
#3 0×0000000000461570 in std::vector<std::string, std::allocator<std::string> >::operator= ()
#4 0x00000000004656c7 in std::vector<std::string, std::allocator<std::string> >::operator= ()
#5 0x00000000005efc9f in Imf::TypedAttribute<std::string>::typeName ()
#6 0x00000000005fd890 in Imf::TypedAttribute<std::string>::typeName ()
#7 0x00000000005fe5d8 in Imf::TypedAttribute<std::string>::typeName ()
#8 0x000000000045d6dc in std::vector<std::string, std::allocator<std::string> >::operator= ()
#9 0x00007f7ffd80d9cf in thread_proxy ()

from /usr/pkg/lib/libboost_thread.so.1.45.0

#10 0x00007f7ffd00b24e in pthreadcreate_tramp (cookie=<value optimized out>)
at /archive/cvs/src/lib/libpthread/pthread.c:473
#11 0x00007f7ff8871780 in _lwp_park50 () from /usr/lib/libc.so.12

Please advise on how to proceed.

If you abort a render with ^C, Povray exits with a ‘success’ error code.

To test:

povray scene.ini
(^C to abort it)
echo $?

Right now 0 is returned (’success’). A non-zero value should be returned (’failure’).

This is particularly important for scripting, where command lines like:

povray scene.ini && halt

...can be used. I only want the halt to be executed if the scene renders successfully. If I change my mind and ^C it, I don’t want the machine to shut down!

How to reproduce:

# An empty directory, an empty source file.
$ mkdir test && cd test && touch test.pov
# Generate the first 24 frames.
$ povray -D +KFF24 +Itest.pov +Otest.png
# Try to generate the 25th frame.
# `25' after `+KFF' can be changed to any integer greater than 24.
$ povray -D +C +KFF25 +Itest.pov +Otest.png

What happens:

==== [Parsing...] ==========================================================
Possible Parse Error: Cannot find file 'test.pov', even after trying to append
 file type extension.
Parse Error: Cannot open input file.
Fatal error in parser: Cannot parse input.
Render failed

OS: Gentoo AMD64 unstable
POV-Ray version: 3.7.0 rc5

...for instance nVidia’s CUDA architecture, discussed here and other places.

General consensus is that it’s not worth the effort if only a partial set of POV-Ray’s features are possible.

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.

I’ve got an ini file that looks like this:

Post_Frame_Return=U
Post_Frame_Command=notepad.exe

And when I render a scene using that ini file, it renders correctly but then
gives me this error:

Render halted because the post-frame shell-out (’notepad.exe’) requested POV-Ray
to generate a user abort.
Render failed

.....and it doesn’t open notepad.

I’ve unchecked the “Disable Starting Other Programs” and I’ve tried various
variations on what exe to run and whether to do it Pre/Post Frame/Scene, and
nothing has worked.

There are times when scaling an entire scene up or down is difficult or just not feasible.

One suggestion is a global_settings option.

Also, I’ve noticed that in some situations, such as interactions between certain transparent objects, the epsilon seems to kick in quite early. Perhaps there could be situational or contextual epsilons, such as the “tolerance” of sphere_sweep or the “accuracy” of isosurface.

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.

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

REcently I installed POV-Ray tracing software in my mac OS X version 10.6.8. When I run the software its displaying a fatal error occured and the error number is -43. I’m new to POV-Ray...pls help me guys...

Source code inspection during examination of issues with the scene published at http://povray.sitewww.ch/?p=177 show the following issues with current (beta.34) implementation of dispersion in POV-Ray 3.7:

• The same adjustment to the IOR that is applied at the very first dispersion interface is erroneously applied to all subsequent interfaces.

• As an exception, dispersion adjustment is erroneously not applied to any interface defined by the surface of a non-dispersing object embedded into a dispersing object.

While this still allows to use dispersion for artistic effect, it is neither physically realistic, nor does it match 3.6 behavior.

The function of the “Debug_File=” .ini option has changed from 3.6 to 3.7.37a.
In 3.6, when rendering multiple frames, a debug file would be created that then appended the debug lines for each frame into the file. It was therefore able to have debug data that identified what parameters were used in which frame in case a frame did not have the desired effect.

In 3.7.37a, the debug file does not perform this function. Instead it creates a new debug file (overwriting the prior) with each new frame. Therefore the debug data is only useful for the final frame (or wherever the render was halted). This is useful for a single frame render or for identifying a fault within a series of frames (because only the last one will remain) but it is not useful for many frames that render successfully.

This problem does not cause any rendering errors or other defects. The debug file specified will only contain the debug data for the last frame rendered.

Per discussion in the forum it was unknown if this was a bug or “feature”. At this time it is causing me a problem so I am submitting the bug. No related bugs were found searching for “output” or “debug” in any status.

Operating System in use is Windows XP. I cannot test 3.7.37a in additional OSes, but it does not seem like it would be OS-specific.