POV-Ray

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

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

Currently, many POV scenes/include files behave differently depending on the basic units used within the scene. Scaling them differently can affect things like ior and media. A master system variable that users can set to configure the scene’s units would be beneficial for sharing and collaboration purposes, so that person A’s glass interior works correctly in person B’s wine glass scene. Just like the #version system variable, it should have a default value but should be possible to explicitly override.

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.

Using the concat function is tedious. Why not just have an operator with which to concatenate strings?

“Hello " + “world!”

“Hello " . “world!”

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

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.

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 ?

Test bug for checking features of flyspray.

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

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.

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

From post in povray.general (circa 29 september 2010: “Maximum Resolution of Renders?”)

The ultimate goal would be a 41000×41000 image. However each time I have attempted to render that Pov-Ray has crashed on
me. Even when using a single, simple test object (a plain white sphere that
should use a single pixel). So I think this is running into a program limitation
at present.

It won’t be for the faint hearted: a 30500 x 30500 does still produces the bug, but you’d better have 24 GB of true ram to test it.
(it’s a render of a few “real” minutes if you do not swap, for any very quick scene (a 305 x 305 in 0.117s moved to 220s for 30500×30500 on my system when corrected))

With core-dumped enable, the issue is pointed in the creator of PixelContainer.
The problem is due to the resize() parameter: despite the parameter being a size_t (8 bytes long on 64bits), the computation ( h * w * 5 ) use unsigned int for h & w (and signed int for 5).

As a consequence, the value of resize is computed as a signed int... havoc might happen when the signed bit (#31) is propagated to the #63 to #32 of size_t... vector does not enjoy a negative value for resize (and destroy itself: no iterator on coming soon call! hence the crash when the values in the vector are to be initialised)

30500²: (in hex)

1 15 3C 71 50 floats
4 54 F1 C5 40 bytes

Basic solution: promote the 5 to an unsigned long, forcing the computation to happen on unsigned long, avoiding promotion of silly sign-bit, and keeping the resize’s value as a good number.

aka: resize( w * h * 5) becomes resize ( w * h * 5ul )

This solution has been tested and seems fine (it’s just that in base/image/image.cpp, there is a lot of resize()!).
For all resize(), the “ul” must be added. (and that means also that resize( w * h ) must be rewritten as ( w * h * 1ul ). )

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.

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.

Trying to build povray-3.6 against png-1.5 fails spectacularly.

.../include/png.h:666: error: forward declaration of ‘struct png_info_def’ png_pov.cpp:1405: error: invalid use of undefined type ‘struct png_info_def’

appears a lot in the output.

The problem is that png-1.5 hides structure members from public view.

Note, this is not the same problem as  FS#144 .

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

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.

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.

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.

Lines 1217, 1241 and 1242 of benchmark.cpp must be change to use #declare instead of local for A and its elements.
(because A is returned by the macro)

	"#macro L_GetVN(ResSpl)\n"
	"   #local I = 0;\n"
	"   #declare A = array[ResSpl+1][2]\n"                      //  <============== this is line 1217
	"   #while (I<=ResSpl)\n"
	"      #local P0 = 0+<FnA(I/ResSpl), I/ResSpl, 0>;\n"
	"      #if (P0.x=0 & P0.z=0)\n"
	"         #local P0 = <1e-25,P0.y,1e-25>;\n"
	"      #end\n"
	"      #if (I=0)\n"
	"         #local P1 = 0+<FnA(((I-0.5)/ResSpl)), I/ResSpl, 0>;\n"
	"         #local P2 = 0+<FnA(((I+0.5)/ResSpl)), I/ResSpl, 0>;\n"
	"      #else\n"
	"         #local P1 = P2;\n"
	"         #local P2 = 0+<FnA(((I+0.5)/ResSpl)), I/ResSpl, 0>;\n"
	"      #end\n"
	"      #local P3 = vrotate(P0,<0,1,0>);\n"
	"      #local P4 = vrotate(P0,<0,-1,0>);\n"
	"      #local B1 = P4-P0;\n"
	"      #local B2 = P2-P0;\n"
	"      #local B3 = P3-P0;\n"
	"      #local B4 = P1-P0;\n"
	"      #local N1 = vcross(B1,B2);\n"
	"      #local N2 = vcross(B2,B3);\n"
	"      #local N3 = vcross(B3,B4);\n"
	"      #local N4 = vcross(B4,B1);\n"
	"      #local N = vnormalize((N1+N2+N3+N4)*-1);\n"
	"      #declare A[I][0] = P0;\n"                               // <============== this is line 1241
	"      #declare A[I][1] = N;\n"
	"      #local I = I+1;\n"
	"   #end\n"
	"   A\n"
	"#end\n"

Same update should also be reported into the distributed scene benchmark.pov

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

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

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

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

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.

I’ve had a series of what appear to be a hang up’s. They passed parse, reported some stats and issued the Rendering... message and opened the preview window, but never progressed. They continued to accumulate cpu time until I eventually had to kill -9, softer didn’t work.

I’ve been dismissing them up until now wanted to speak up because I finally got this crash:

29623 Segmentation fault

Here’s some observed behaviors:

In my scene I have a Round_Box_Union with /just/ a pigment that rendered fine, but when I added a wood texture from the distribution includes, it hung up after I tried to transform the texture in any way. Tried other distribution textures ... same thing.

I spent time going through different scenarios looking for a common cause (thinking I’m doing something wrong). Eventually I arrived at the point that I killed a hung render, and restarted the same render with no changes. Sometimes it would render, sometimes not ... I finally got the above mentioned Round_Box_Union to behave with a simple reflective texture, and the rounding parameter had to be above 0.1 ... I settled at 0.125. OK by now you’re thinking WTF right?

No more problems until I accidentally (typo) put an additional light_source at the same location as another light_source. It also hung sometimes, and rendered fine sometimes after a kill ... no SDL changes.

Now I can’t tell you exactly what I was doing when the seg fault happened, but I /do/ know I just restarted the render with no changes. I’m starting to think there’s some kind of instability happening here. I realize that I’m probably the only team member spending any real time with the application, so none of you probably haven’t noticed anything suspicious.

Any comments ... ideas ... suggestions?

When using mesh_camera type ‘0’

The first line of the mesh output seems to be repeated resulting in incorrect light colour values.

If the first line of the texture is skipped then the values seem to be correct.

The documentation states mesh_camera 0 should produce 1 pixel per index but it currently seems to produce 1 lighting pixel per face.

This output seems fairly meaningless as using this data for vertex colours (presumably the intention for mesh_camera 0) would result in a flat shaded model.

Logically it would make more sense to output 1 pixel per vertex instead of 1 pixel per face. Another solution might 1 pixel per face index (as per documentation) although POV would need to record which indices had already been computed otherwise it could end up duplicating computation.

At the moment I’ve written a code workaround for my exporter which produces a special mesh but this is obviously a much more complex solution to a fairly simple problem.

As I posted yesterday to the POV bugreports, I observed a bug with the #write directive, having forgotten the closing bracket. I looked a little bit closer and found different behaviours of POV with different array sizes.

With ArrayDim=100 (please look at the attached SDL-code, which is reduced as much as possible and produces only the bug and no scene) one get the Parse Error: “Expected ‘string’, End of File found instead” and the last line is highlighted. With ArrayDim=1024 you get an Stack Overflow and POV crashes.

I observed this at two different core i7 windows machines. On one of them (16 GB RAM, if this is of importance) the threshold between both behaviours was between 300 and 400. Hope this helps.

Best regards,
Michael

Originally resolved in https://bugs.gentoo.org/show_bug.cgi?id=425450.
Attached is a patch with Gentoo-specific code removed.

There are two parts in this issue:

• The newer boost library requires downstream users to explicitly link to the boost system library (-lboost_system).
• The newer boost library replaced TIME_UTC with TIME_UTC_, because glibc added TIME_UTC.

Output images are 0.5 pixels too right and 0.5 pixels too down (mesh_camera_bug.pov).

The error is cumulative when image files are used again as texture (run 10 times mesh_camera_bug_reuse.pov).

This can be compensated by adjusting UV maps (mesh_camera_fix.pov and mesh_camera_fix_reuse.pov).

Tested with and without anti-aliasing.

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.