POV-Ray

When rendering for some time, it occasionally happens that POV-Ray appears twice in the Windows taskbar. One button is the normal one, the other one does not open any window when clicked on and reads something like “99% complete” (see attached image), like the render window’s title, but obviously unrelated to it (probably the title the render window had shortly before?). After stopping the render, the odd taskbar button remains there until POV-Ray is closed.

• Observed under Windows XP
• POV-Ray 3.7.0.RC7.msvc10-sse2.win32
• When applications are summarized into groups in the taskbar by Windows, the odd POV-Ray button is attached to the Windows Explorer group
• Run with render priority set to “high”

Is this a Bug in Windows or in POV-Ray?

When a command-line parameter in an .ini file cannot be parsed (such as “+a.3”), POV-Ray reports a “Problem with setting”, quoting the command line, rather than indicating that the problem occurred in an .ini file. This leads the user to think that the problem is with the command line itself, unnecessarily confusing him.

On a very long render, around day 24, the elapsed time display becomes incorrect, showing 4294967272d 4294967272h 4294967272m 4294967272s.

Found on Windows 7 64 bits and reproduced on Windows 7 32 bits.
NOT reported on other platforms.

Tooltip popup for render speed always displays as “Pixels per Second” rather than matching status bar. I’ve noticed it in 3 renders so far. Most of my renders are fast enough not to see any other unit besides PPS, but I should be able to reproduce again if necessary.

This doesn’t work:

#declare pavement_object = array[2]
{

object {trash_can_macro()	scale 3/4			translate -x * 1/2},
object {potted_plant_macro(_CT_rand2)	scale 3/4	scale 3/2	translate -x * 1/2}

}

This does work:

#declare trash_can_object = object {trash_can_macro()};
#declare potted_plant_object = object {potted_plant_macro(_CT_rand2)};
#declare pavement_object = array[2]
{

object {trash_can_object	scale 3/4			translate -x * 1/2},
object {potted_plant_object	scale 3/4	scale 3/2	translate -x * 1/2}

}

Logically, I cannot see a reason for this to be so.

Subsurface Scattering still uses its own rudimentary code to compute illumination from classic light sources; this must be changed to use the standard light source & shadow handling code, to add support for non-trivial light sources (e.g. spotlights, cylindrical lights, area lights), partially-transparent shadowing objects etc.

Windows UI code should be refactored to use _TCHAR throughout instead of char, as well as the corresponding string function macros, to head for Unicode support.

In the files bezier.cpp, fpmetric.cpp, fractal.cpp, hfield.cpp, isosurf.cpp, lathe.cpp, poly.cpp, polygon.cpp, prism.cpp, sor.cpp, and sphsweep.cpp the use of POV_MALLOC can be replaced by std::vector quite easily because the containing class already is a C++ class. As this is a low hanging fruit for continued code cleanup, it should be done sooner rather than later.

Subsurface scattering must be made photon-aware.

For proper render abort/continue support, radiosity cache data must be written to (or read from) disk even if the user does not explicitly opt to have a sample data file written/read. This feature has temporarily been dropped from 3.7 beta and is still pending re-implementation.

To meet high-reproducibility requirements in conjunction with SMP operation, it may be necessary to extend the 3.6 radiosity cache file format.

Near concave edges, radiosity samples may be re-used at a longer distance away from the edge than towards the edge; there is code in place to ensure this, but it only works properly where two surfaces meet roughly rectangularly, while failing near the junction of three surfaces or non-rectangular edges, potentially causing “cross-talk”.

It should be investigated how the algorithm can be improved or replaced to better cope with non-trivial geometry.

Some features are optional in custom builds of POV-Ray (I’m thinking about OpenEXR in particular); it would be nice to have a syntax for an SDL script to check for support of such features, so it may take some fallback action if the feature is not supported.

Just like radiosity load/save, the photon mapping load/save mechanism should be moved to the frontend and controlled via command-line switch, instead of being SDL-driven in the backend.

Warnings should be raised when a command line option has no effect,
for example...

pvengine +am

is legal, but without the number after it, it has no effect.

pvengine +am7

should be an error, and also raises no warnings.

Front- & Back-end code should be refactored for full Unicode support in scene files and strings.

Most sample scenes and include files were designed at times when POV-Ray did not to any proper gamma handling, or still used the inferior 3.6 “assumed_gamma” mechanism.

All the scenes and include files should be reviewed, and updated to fit the new 3.7 gamma model.

The primary task will probably be gamma-adjusting literal color values and ambient parameters; I suggest using macros (which ideally should be defined in an include file) to be set according to the #version statement, so the scene/include file could be kept compatible with older versions.

With previous versions of POV-Ray, it was possible to turn off display output, but still assess the output during render by viewing the output file as it was progressively generated. This allowed e.g. to run a long render on a remote machine as a background process, and check the output from time to time via FTP or similar.

This is a list of unimplemented features and things to fix with respect to 3.7 vs 3.6 compatibility. They either need to be fixed in code, or failing that, to be documented prior to release.

Create_INI works differently from 3.6. Prior versions of POV-Ray would write all options to the file, even if they were not supplied by the user (non-supplied options would take the default value). Currently in 3.7, only supplied options are written, because the front-end does not send unused options to the back-end. The proper fix for this would be to have a set of defines that establish the defaults all in one place (currently we rely on hard-coded values scattered around the code), and for the Output_INI_Option() function to look up and use the default when not supplied. As this is not likely to be done before 3.7 release, we need to document it as a temporary situation.

The following messages are marked as ‘currently not supported by code’ in povmsgid.h. We need to check where this comment is correct and if so the docs need to be updated to indicate this (for items that are already documented). Some items may be re-implemented later, and some may never be:

• kPOVAttrib_TestAbort
• kPOVAttrib_TestAbortCount
• kPOVAttrib_VideoMode
• kPOVAttrib_Palette
• kPOVAttrib_DisplayGammaType
• kPOVAttrib_FieldRender
• kPOVAttrib_OddField
• kPOVAttrib_AntialiasGammaType
• kPOVAttrib_LightBuffer
• kPOVAttrib_VistaBuffer
• kPOVAttrib_DrawVistas

This bug should be edited to add/remove items as time goes by.

The syntax notation used in the main documentation is different than that used in the quick-reference section. This should be changed for consistency, using the superior quick-reference notation throughout.

See this documentation entry for more details.

The sphere_sweep renders well when specified directly, but when it is scaled, its bounding box is calculated incorrectly, which clips the object so it almost disappears.

The effect is present for all three types of splines.

I’m attaching a test scene and the rendering result. The saving of the object with #declare has no effect, I just wanted to show both transformed and untransformed version.

I don’t think this issue is related to other artifacts occuring with sphere_sweep, as it is obviously an issue of the internal bounding box.

In the photons map, the direction of each photon is stored as separate latitude & longitude angles (encoded in one byte each), causing the longitudinal direction component’s precision to be unnecessarily high for directions close to the “poles” (Y axis); in addition, encoded value -128 is never used. For better overall precision as well as precision homogenity, the following scheme could be used instead:

• Encode the latitude (-pi/2 to +pi/2) into LatCount=226 distinct values (= 256*sqrt(pi)/2) rounded to the next even number) from 0 to LatCount-1 using

latCode = (int)((LatCount-1) * (lat/M_PI + 0.5) + 0.5)

• For each latitude code, define a specific number of encodable longitude values, LngCount[latCode] = approx. cos(lat)*pi*65536/(2*LatCount); this can be a pre-computed table, and may need slight tweaking for optimum use of the code space. Encode the longitude (-pi to +pi) into a value from 0 to (LngCount[lat]-1) using

LC = LngCount[latCode];
lngCode = (int)(LC * (lng/(2*M_PI) + 0.5) + 0.5) % LC;

• Besides LngCount[latCode], also store the sum of LngCount[i] with i < latCode as LatBase[latCode]; encode the direction as

dirCode = LatBase[latCode] + lngCode;

• For decoding, a simple lookup from a precomputed list of directions could be used (2^15 entries, i.e. one hemisphere, will suffice). To conserve space, direction vectors could be scaled by (2^N-1) and stored as (N+1)-bit signed integer triples rather than floating point values; due to the limited precision of the lat/long information, 8 bits per coordinate might be enough, giving a table size of 96k. A full double-precision table would require 786k instead.

A low priority thought for the future: isosurface now only allows contained_by to be a sphere or a box. It would be more intuitive to allow the same objects that are allowed in clipped_by and bounded_by (although it probably needs to be finite). It would enable allow much faster rendering in many cases:

1) There are a lot of cases when the sphere or a box are very bad in bounding - if an object has a hole, a torus may be better, and in many cases, cylindrical bounding would help a lot.
2) Sometimes, having a too large contained_by object includes far-away parts of the iso-function, and expose large gradients that you want to avoid. If a bounding object is better, you can decrease the max_gradient and speed up the render.
3) The isosurface is usually much more expensive to calculate than any normal bounding object, so it’s an improvement even if the intesection test is not as fast as bounding box.
4) A typical case: if you use texture-like functions to make the surface realistically rough, you know almost exactly what the bounding object is - it can be the original unmodified object.
5) For isosurface terrains, a preprocessing macro could create a rough mesh-like bounding object to contain the “mountains”, thus making everything faster.
6) In case you want clipping, having the contained_by set to the same object probably avoits calculating too many intersections.

The main modification is probably that the intersections of bounding objects can be split into more than one interval - but it’s probably worth it, the isosurfaces are usually a speed bottleneck.