POV-Ray

User reported documentation inconsistency. Investigation led to the discovery of a bug in the setting of the current default value.

~source/frontend/renderfrontend.cpp reports the value “3” while ~source/backend/scene/scene.cpp sets a default value of “1”

Before for addressing this issue, are there any thoughts as to what the default value should be?

Due to a typo in the conf file parser (introduced, I think, in refactoring after 3.6), the restricted setting is ignored, and access checks aren’t performed.

Fixing this reveals some other issues:

• %INSTALLDIR%/../../etc is incompletely canonicalized to /usr/local/share/../etc, not /usr/local/etc
• read+write paths are added to the read list only, so writing is impossible

See attached patch.

Relatedly, I think it would be nice to add a new replacement token %CONFDIR% instead of %INSTALLDIR%/../../etc.

Also, there’s a realpath function that could simplify path handling, though I’m not sure if it’s available on all platforms.

When rendering in multiple passes (radiosity in my case), the elapsed pixels and percentage, written to terminal
are first displayed like this:
Rendered 126202 of 360000 pixels (35%)
Then on the second stage the output text becomes shorter and you see
Rendered 25344 of 360000 pixels (7%)%)
The contents of the previous status are not erased, so the longer text persists (note the duplicate percentage sign and closing parenthesis). Such a glitch could have more drastic effect in rare cases.

I’m running
Version 3.7.0.RC3 (g++ 4.6.2 x86_64-unknown-linux-gnu)
compiled for the Arch Linux package.

When using OpenEXR output file format, POV-Ray erroneously reports it as “24 bpp EXR” in the message output, while in fact it generates a 3×16 = 48 bpp file.

Currently POV-Ray does not support rendering lens flare effects, however, they can be simulated using a macro (include file) by Chris Colefax.

I would like to suggest adding a feature to POV-Ray to support lens effects “natively” since

• as far as I know the macro has been designed for POV-Ray 3.1 so with each new POV-Ray version it gets more likely that this macro does not work properly any more
• the macro does not work when rendering with radiosity, probably because the macro creates the lens effect by using a pigment with a high ambient value (which is ignored by POV-Ray 3.7’s radiosity algorithm).

Additionally, the macro is not quite easy to employ because

• it needs to know the exact camera parameters (location etc.) and defines an own camera itself so any important camera information has to be stored if the effect has to work as expected
• it does not (actually cannot) take into account that objects may (partially) hide the lens effect
• reflections and refractions (of light sources) cannot be combined with it properly - the user would have to calculate both the point where the reflected/refracted light source can be observed and the shape it then has due to distortion, and in more complex scenes such computations are nearly impossible in SDL.

I would suggest integrating such a lens flare rendering feature with the “looks like” mechanism you already have for light sources. Several parameters that can currently be set for the macro - including effect brightness and intensity, lens options and whether to create a flare at all - could be set for the light source.

Then POV-Ray could store the location and colour of each ray that finally intersected the “looks like” object of a light source and, having finished the main rendering, from that data compute a partially transparent “lens flare layer” eventually mixed into the rendered image. By this, the above mentioned problems could be avoided:

• an object fully or partially intersecting a light source’s “looks like” object would also reduce the number of pixels used to create a flare - and therefore reduce that flare until fully hiding it
• the same goes for reflected and/or refracted versions of the “looks like” object
• the camera’s location and other properties would be used automatically
• and finally, as a feature supported by POV-Ray itself, there would be neither compatibility issues nor problems like the effect not fitting together with radiosity.

Do not get me wrong, I would not expect POV-Ray to really calculate intersections that naturally happen in a camera lens, causing lens flares. Effects looking appropriate can actually be created just in 2D space (as some graphics programs do support) so the work to be done would, as far as I have any overview, be:

• storing, as mentioned above, the relevant data for pixels showing “looks like” objects
• calculating a lens flare from that data after the render has finished
• overlaying the rendered image with the newly created lens effect.

Adding full texture statement support to the background statement (with a scale of 1/1) aligned with the image_map direction of an image would allow i.e. specifying an image as background easily.

The #debug message stream is only being flushed when it hits a newline character,
instead of after each #debug statement. This means that some final strings don’t show up.

#debug "This line prints,\n but this line doesn't."

POV-Ray 3.6, upon encountering problems when parsing command line and/or .ini file options, would quote the offending option in the error message.

POV-Ray 3.7 currently just reports that there is some problem with the command line, without providing any details. I suggest changing this, as the information may be helpful at times.

Currently, radiosity does not make use of the fact that pertubed normals would theoretically just require a different weighting of already-sampled rays, leading to the following issues:

• Honoring normal pertubations in radiosity leads to an increased number of samples, slowing down sample cache lookup.
• The increased number of samples is generated from a proportionally higher number of sample rays, slowing down pretrace even further.
• Low-amplitude pertubations tend to be smoothed out; “reviving” these is only possible by increasing the general sample density.
• Handling of multi-layered textures with different normal pertubations is currently poorly implemented.

As a solution, I propose to store for each radiosity sample not only the resulting illumination for a perfectly unpertubed normal, but from the same set of sample rays also compute the illumination for an additional set of about a dozen standardized pertubed-normal directions, and interpolate among these when computing the radiosity-based illumination for a particular point that has a pertubed normal.

For backwards compatibility, this method of dealing with pertubed normals in radiosity might be activated by a different value for the “normal” statement in the radiosity block, say, “normal 2”.

Being able to have functions operate on vectors would be pretty nice to have.

Hi,

it would be nice if there exists a test scene (not a benchmark) which has a high coverage of povray source and can be used as correctness validation of povray. It schould be produce an image which can be compared to a golden reference image.

It may be also possible to create a regression test suite which does automatic comparision of the render results.

Background

Possible solution

There is an big issue with the slope pattern: when the object it is applied to is instanced (again) with a transformation (in particular a rotation, as a translation would not impact.. but a shear might), the colours of the surfaces are changed.

  
object { p translate -5*x }
object { p rotate 220*y+20*x    translate 3*x }       

Nobody would expect the object to be different in appearance.
If slope {} is replaced with wood, all is fine. (as for others textures, i guess)

IMHO, the slope vector need to be adjusted for the later transformation(s) (so as to compensate the issue of using the Perturbed Normal vector).

This should not impact the AOI/FACING (experimental) patterns, as AOI definition is pretty clear about duplicating & transform if you think about it a bit, as well as FACING: for these two, it is expected to either use the ray(current point of view) or a fixed 3D point as reference. At the limit, discussion about moving the 3D point of FACING might also be opened to interpretation.

AOI/FACING are in task #19

User-defined warps would be nice to have, something along the lines of:

warp {
  function { MyFnX(x,y,z) } // function to compute pattern-space x-coordinate from object-space <x,y,z> coordinate
  function { MyFnY(x,y,z) } // ditto for pattern-space y coordinate
  function { MyFnZ(x,y,z) } // ditto for pattern-space z coordinate
}

// a displacement warp:
warp {
  function { x + MyFnX(x,y,z) }
  function { y + MyFnY(x,y,z) }
  function { z + MyFnZ(x,y,z) }
}

motion_blur which is a simple and effective feature to use in Megapov to simulate motion blur of, e.g. bird wings, propellers or running animals, would be a neat addition to version 3.7 and later.

In Megapov, the feature requires a line of code in the global_settings{} e.g.: motion_blur 10, 2
and a declaration for the moving object. e.g.:

motion_blur {
  type 0
  object{MyObject  material{MyMaterial rotate x*clock*2}}
  rotate x*clock*10
}

type represents several types of pre-defined motions.

Thanks,

Thomas

Think this is still a problem. See the attached scene file. Find the WindowFrameSegment declaration for more info. The scene as-is shows the problem (SOME portions of the difference inherit the color of the room) the window opening is scaled larger to show that they AREN’T touching. The problem goes away when (in WindowFrameSegment) the 1st occurrence of the applied texture is commented out and the 2nd occurrence is uncommented, and cutaway_textures is commented out.

Currently, fading light sources are used for lighting and shadow
calculations even when so far away as to no longer have any effect
on the outcome. The proposed solution is to add a new keyword
fade_cutoff_distance which tells povray to ignore the light
source when alluminating a point at larger distance.

A sample implementation is provided in the attached files. These
changes are still based on beta 34 as sources for the current beta
are not yet available, and starting to merge changes to beta 35
only at this time didn’t seem worth the effort. Also, please
disregard, changes in the CVS header comments (I also use
CVS locally for managing source files).

Further considerations regarding this feature:

- For special effects this feature can also be used if the light
source does not actually use fading. On the other hand, cutting
the light at some distances can be considered an extreme form
of fading which may justify the keyword name anyhow.

- Depending on how  FS#46  is implemented, the test for cutoff may
then be needed at another location as well.

- The default value currently is 0 (or *no* cutoff distance). For
#version 3.7 of higher, the default could be chosen automatically
based on the light source intensity and adc_bailout, although it
may then need to be overriden by the user for extreme pigments.

Currently, arrays are of a fixed size. You can’t add or remove items to/from an array. I think it would like arrays to be expandable with no fixed and pre-determined size.

See Notepad++ or EditPad Lite for examples.

It would be nice to be able to drag tabs in the editor window to change their order, so as to group opened files together by relevance for instance.

Would be great if there were a “Rename” option in the editor File menu to rename the current file name. Otherwise, you have to close the file, rename it in file manager, then open the file again, thus loosing the current tab position and undo history for the file.

Would be great to have a “Reload” option in the File menu to manually reload the current file from disk, discarding all subsequent changes since the last save.