I have installed POV-Ray 3.7 beta 34 on Windows 7
The setting ‘Output_Alpha=on’ doesn’t work as documented. With this setting the Background appear black and the scene is transparent.

Check with this Code:

camera {
   location  <3, 3, -3>
   direction <0, 0, 2.9>
   look_at   <0, 0, 0>
   right 1.0*x
}
light_source { < 3, 3, -3> color red 1 green 1 blue 1 }
sphere 
{
   <0,0,0> 0.8
   pigment {color rgb<1,1,0>}
   finish
   {
      ambient 0.2
      diffuse 0.8
   }
}

and with this ini file:

Input_File_Name=C:\Users\dfv_rei1\AppData\Local\Temp\Cuadrigula\PreviewObject.pov
Output_File_Name=C:\Users\dfv_rei1\AppData\Local\Temp\Cuadrigula\PreviewObject.tga
Output_File_Type=t
Output_Alpha=on
Bits_Per_Color=24
+W121 +H121
+a0.3
+q11
+a

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

The attached TIFF file was created with IC using compression. When used in an image_map, POV-Ray 3.7.0.beta.34 on Windows XP x64 renders the image all transparent, while POV-Ray 3.6.2 renders the file fine. The same effect can be seen with LZW-compressed TIFF files created with Adobe Photoshop 6.0.

Uncompressed TIFF files created with either IC or Photoshop render fine in both versions of POV-Ray.

Stepping through the code of POV-Ray 3.7.0 shows that the same code path is taken regardless of compression, but the libtiff library returns different alpha channel values, indicating a problem in that library. POV-Ray 3.7 still uses libtiff 3.6.1, whereas the POV-Ray 3.6 branch has been updated to libtiff 3.8.2, which according to the change history includes a few alpha-related changes.

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.

Reported by cshake + pov @ gmail . com in p.beta-test, 14th december 2009

I wrote a simple script to convert fractint color maps to povray color_maps so I could use ApoMap to make nice fractal colors for pov, but I ran into
“Parse Error: Blend_Map too long.” The map has entries from 0/255 up to 255/255 (inclusive). I looked up the documentation which says that color_maps can have from 2 to 256 entries, and this is exactly 256 entries.
I’m posting this in beta-test because I assume that the documentation is correct for v3.6, and that a previous version can handle 256 entries.

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

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!

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

The following scene shows how photons are “boosted” by pass_through objects; removing one of the boxes will reduce the effect; the effect can be seen with 3.6 as well as current betas:

global_settings {
  max_trace_level 10 // makes a difference!
  photons { spacing 0.02 }
}

camera {
  right x*image_width/image_height
  location  <0,2.6,-10>
  look_at   <0,0.75,0>
}

light_source {
  <500,500,150>
  color rgb 1.3
  photons {
    refraction on
    reflection on
  }
}

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

plane {
  y, 0
  texture { pigment { color rgb <1.0, 0.8, 0.6> } }
}

#declare M_Glass=
material {
  texture {
    pigment {rgbt 1}
    finish {
      ambient 0.0
      diffuse 0.05
      specular 0.6
      roughness 0.005
      reflection { 0.1, 1.0 fresnel on }
      conserve_energy
    }
  }
  interior {
    ior 1.5
    fade_power 1001
    fade_distance 0.9
    fade_color <0.5,0.8,0.6>
  }
}


sphere {
  <1.1,1,-1.3>, 1
  material { M_Glass }
  photons {
    target 1.0
    refraction on
    reflection on
  }
}

cylinder {
  <-1.2,0.01,0.8>, <-1.2,2.5,0.8>, 1
  material { M_Glass }
  photons {  // photon block for an object
    target 1.0
    refraction on
    reflection on
  }
}

box {
  <2.4,0,-2.3>, <2.6,4,-0.3>
  material { M_Glass }
  photons { pass_through }
}

box {
  <2.9,0,-2.3>, <3.1,4,-0.3>
  material { M_Glass }
  photons { pass_through }
}

source/png_pov.cpp included in povray-3.6.1 contains calls to an internal function of libpng (png_write_finish_row) which was removed from the public interface quite a while ago, so linking fails.

Also, in the 1.4 releases of libpng, the info_struct “trans” member was renamed to trans_alpha. This causes a compilation error in the same file.

A suggestion for the solution:
a) remove the png_write_finish_row prototype and function call
b) add something like:
#if PNG_LIBPNG_VER < 10400
#define trans_alpha trans
#endif
and change
cmap[index].Transmit = 255 - r_info_ptr→trans[index];
to
cmap[index].Transmit = 255 - r_info_ptr→trans_alpha[index];
(two occurrences).

Compiled on linux (revision #5066),
./configure COMPILED_BY=”###” –disable-io-restrictions

the command: povray –benchmark

is failing:
Failed to parse INI file

povray –version

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.4.3
Compiler flags:      -pipe -Wno-multichar -Wno-write-strings -fno-enforce-eh-specs -s -O3 -ffast-math -march=native -pthread 

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.

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.

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

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

[Original Title: “texture_map interpolation does not work correctly for some patterns”]

The below test scene should yield identical textures
T_STRAND1 and T_STRAND2 but this is not the case. Reported
and verified in

http://news.povray.org/povray.general/thread/%3C4cbd804b%241%40news.povray.org%3E/

The problem seems to affect bozo, bumps, dents, granite, spotted,
and maybe wrinkles. The problem was reported earlier in

http://news.povray.org/povray.beta-test/thread/%3C48112367%241%40news.povray.org%3E

with a comment that 3.6 gives the expected results

#declare C_STRAND = color rgb 1;

#declare C_CLEAR  = color rgb 0;

#declare T_STRAND = texture
{
  pigment {color C_STRAND}
}

#declare T_CLEAR = texture
{
  pigment {color C_CLEAR}
}

#declare T_STRANDS1 = texture
{
  pigment
  {
    granite scale 2 color_map
    {
      [0.0 color C_STRAND]
      [0.5 color C_CLEAR]
      [1.0 color C_CLEAR]
    }
  }
}

#declare T_STRANDS2 = texture
{
  granite scale 2 texture_map
  {
    [0.0 T_STRAND]
    [0.5 T_CLEAR]
    [1.0 T_CLEAR]
  }
}

plane
{
  z, 10
  texture {T_STRANDS1}
  //texture {T_STRANDS2}
} 

I/O Restriction defaults are not being properly set on a fresh install of POVWIN.

See this thread for more information.

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.

Given the following two statements, a missing closing brace in the function declaration fn should throw a parse exception; instead it causes a memory access violation when trying to use fn in the second delcaration:

#local fn = function { 
  pigment { image_map { png "MultiPassBlobs3.png" gamma 1 map_type 0 once }} 
#local clr = fn(0,0,0);

in change #3319, csg got a new computation for its weighted textures.

But I’m confused by the computation of the weight: (circa end of csg.cpp file)

COLC weight = 1.0f / min(COLC(textures.size() - firstinserted), 1.0f);

I would have used a max() rather than a min().

It is transparent when there is only one texture, but:

• should there be no texture (an error...): it would be a division by 0
• should there be more than 1, the weight of each would be 1. which is without consequence UNLESS there is already some other textures in the list. The right value (from previous code) was 1/n

Or did I get a confusion about min() ?

min(0,1) == 0
min(4,1) == 1

Using max would protect against the division by 0 and the right value when multiple textures are used.

Any thought ?

UV-mapped textures for parametrics are broken in POV-Ray 3.70 RC3, in cases where two (or more) parametrics overlap in a scene.

In the following scene, note how the texture per se is always taken properly from whichever parametric is in front, while the UV coordinates are erroneously taken always from the red parametric where both overlap, no matter whether it is in front or back.

camera {
  location  <0.0, 1.5, -3.0>
  direction 1.5*z
  right     x*image_width/image_height
  look_at   0
}

light_source { <-30, 30, -30> color rgb 1 }

#declare Param = parametric {
  function { u*v*sin (15*v) },
  function { v },
  function { u*v*cos (15*v) }
  0, 1
  contained_by { box { -1,1 } }
  accuracy 0.002
  precompute 15 x,y,z
  rotate 180*x
  translate  <0.3,0.5,0>
}

object {
  Param
  uv_mapping
  texture {
    pigment {
      gradient x frequency 3
      color_map {
        [0 color red .5 ]
        [1 color red 1 ]
      }
    }
  }
}

object {
  Param
  uv_mapping
  texture {
    pigment {
      gradient x frequency 7
      color_map {
        [0 color green .5 ]
        [1 color green 1 ]
      }
    }
  }
  rotate y*180
}

POV-Ray 3.62 renders the scene properly.

As this bug has been found during code inspection, the uderlying cause has already been identified; I’m currently working on a fix.

Hello,

this bug report relates to this thread: http://news.povray.org/povray.beta-test/thread/%3Cweb.4e0064d9a3970d212b256d410%40news.povray.org%3E/

In /unix/unixoptions.cpp around line 817:

while ( !Stream.eof() )
{
	// get and preprocess line
	std::getline(Stream, line);
	line = pre_process_conf_line(line);
	++line_number;
	// skip empty line
	if(line.length() == 0)
		continue;
        [...]
}

`Stream.eof()` could never be true as well as `line.length()` always can be zero, leading to an endless loop. In my case, the problem occurred due to my ~/.povray/3.7/povray.conf being a directory instead of a file.

To fix the problem, one has to consolidate this loop by not only checking for eofbit, but also for failbit and badbit of `Stream`. The getline() method on a directory does not set the eofbit, but it sets fail and bad (test: http://codepad.org/RiZGo3ia). According to http://www.cplusplus.com/reference/iostream/ios/operatornot/ fail and bad can be checked for by `!Stream`. A simple `if (!Stream) break;` within the loop fixes the problem (patch file attached).

Are there more missing checks on iostreams like this in the code? :) They should definitely be fixed.

Furthermore, one could think about using the boost filesystem library to be able to distinguish files and directories to provide good error messages.

Hope that helps,

Jan-Philip Gehrcke

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

I reinstall a system, (so ~/.povray was not existant), and then
installed povray from sources, as a normal user (excepted the
installation step):

$ ./configure ...
$ make
$ make check
$ sudo make install

I find these steps pretty much standard.

The problem I’m noticing is that the $HOME/.povray hierarchy get owned
by root (hey, it’s *MY* directory !). There is a chown in the Makefile
for the target files (povray.ini & povray.conf), as well as subtree but:

* povowner & povgroup are hard coded to 0 (I would expect a copy of the
owner & group of $HOME, wouldn’t I ?)

For getting povowner, I would suggest `stat -c “%u” $HOME`
For povgroup, `stat -c “%g” $HOME`

Are they portable enough ? (I could ask on Monday a Solaris system, but
I do not have bsd and the other flavours of unix)

(Stat is in section 1 of man, part of gnu coreutils, /usr/bin/stat)

Side note: This is fine to install for the local user, but new later
users could benefit also from a ~/.povray/3.7/ subtree ; what about also
filling the /etc/skel (when available) ? (and in /etc/skel, root owner
is fine!)

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.

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.

Recently, I have been rendering an animation with POV-Ray 3.7 RC 6 using radiosity, photons and backside illumination. Many frames contained artefacts like in the attached image file. Trying to eliminate those artefacts I observed the following:

• Rendering the same frame several times did not reproduce the artefacts or reproduced them differently. I.e., when I rendered a second (third, fourth, ...) time with +SF100 +EF100, the black space in the image was somewhere else or in some cases disappeared.
• With radiosity turned off, no such artefacts have happened since, even in the scenes where they happened with radiosity turned on.
• Turning off photons with radiosity still turned on did not remove the artefacts.
• Rendering with one thread on one CPU core instead of two threads on two cores did not change anything except the rendering time.
• Changing the radiosity settings I have not tried thoroughly, but at least raising or lowering count or error_bound does not seem to have any effect on this.

While POV-Ray was rendering, no other memory-intensive or CPU-intensive programs were running and POV-Ray itself did not report any error (just the usual warnings that some of the used features could change in future versions etc.). Render priotity was set to “high”.

I would like to suggest an additional feature regarding splines. POV-Ray’s spline objects (spline {}) are very useful to create animation paths as a function of time from reference points; however, in many cases you do not only need a position to place an object correctly, but also its velocity etc., e.g. if you are animating a car moving along a spline you do not only need to know where the car is at a given clock value but also in which direction it is going. If you want to rotate the wheels correctly you even need to know how this direction is currently changing.

In a nutshell, if you are using splines to create an animation path, you might not only need the spline value itself, but also the value of its first and second derivative. So I suggest adding an SDL capability to access these values like it is possible to access the spline value for a given parameter.

I do not think it would be too difficult to add a feature like this as far as the backend is concerned, since for computing a (cubic) spline you need the first and second derivatives anyway. (They are probably not being stored separately, but a polynomial is not that hard to differentiate.)

Indeed I do not know how an SDL language construct for it should look like (i.e. whether to use ' and ‘’ like in mathematics or a second spline function parameter).

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.

Due to a recent thread in povray.general (7th September 2013), I dive
into the code of height field creation.

There is 2 TODO in source/backend/support/imageutil.cpp, for
image_height_at() (circa line 512)

The first one is about using the index of palette-image: As far as *257
would indeed perform a better job to cover the full range than *256, it
would break backward compatibility with previous versions of povray (3.6
included) which only promoted the index as the Most significant byte,
keeping the least one at 0.

But on the second one, the new formula is plain wrong: (r*255+g)*255
should be (r*256+g)*255.
In previous versions, r*255 was the Most significant byte, and g*255 was
the least one.
Ergo, the value was r*255*256 + g*255, which can and should be only
factored as (r*256+g)*255;

I know it is damn late in the release schedule, but can that be either
be fixed before final official delivery or a memo added to the release
note that it would be fixed later and backward-bug will not be
maintained for that specific point (using rgb-8 or less bit per
channel-image for height field)

(it was not bugged in 3.6.1 nor before, it’s just that tiny little bit
of 3.7 that would should that bug)

If you look carefully at the attached pictures (povray +I... +H700 +W700 +A0.01) of scene and scene36, there is a significant difference at the top.
With 3.6, it matched exactly (hence the noise on the top pixels row) the view.
With 3.7, it cannot reach the top and leave a white area
(another difference is the slope on the side are also a bit more lower with 3.7, easier to spot when alternating the display of both pictures)

If you want to regenerate hf.png, it was rendered with povray 3.7RC7, +W400 +H400 +A0.01 +Ihf.pov

The white line at the bottom is expected, as the minimal value of the height field is “full green”

can not run POV-Ray on ubuntu 14.04, boost 1.54,

./configure COMPILED_BY=”Dmitry <my>”

...

Libraries
---------
checking whether to link with cygwin DLL... no
checking whether to enable static linking... no
checking for the pthreads library -lpthreads... no
checking whether pthreads work without any flags... no
checking whether pthreads work with -Kthread... no
checking whether pthreads work with -kthread... no
checking for the pthreads library -llthread... no
checking whether pthreads work with -pthread... yes
checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE
checking if more special flags are required for pthreads... no
checking for boostlib >= 1.37... yes
checking whether the Boost::Thread library is available... yes
checking whether the boost thread library is usable... no
configure: error: in `/home/di/workspace2/povray-3.7-stable':
configure: error: cannot link with the boost thread library

log in attach file

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

The following paraboloid renders correctly:

intersection
{ quadric { <1, 0, 1>, <0, 0, 0>, <0, 1, 0>, -1 }
  cylinder { 0, y, 1 }
}

However, when I extend the clipping cylinder downward:

intersection
{ quadric { <1, 0, 1>, <0, 0, 0>, <0, 1, 0>, -1 }
  cylinder { -y, y, 1 }
}

the object disappears completely in POV-Ray 3.7 and 3.7.1. In POV-Ray
3.6.1, it renders as expected.

POV-Ray 3.7.0.unofficial (self-compiled with g++ 4.8, but completely unaltered)
POV-Ray 3.7.1-alpha.8150025.unofficial
openSUSE 13.2 GNU/Linux

This scene file illustrates the problem:

// +w480 +h240
#version 3.6; //[sic]

global_settings { assumed_gamma 1 }

camera
{ location <0, 1, -7.5958>
  look_at <0, 1, 0>
  right 2 * x
  up y
  angle 43.1038
}

#default { finish { diffuse 0.6 ambient rgb 0.15618 } }

light_source
{ <-4.3125, 9.6250, -7.4695>,
  rgb 6856.3
  fade_power 2 fade_distance 0.10417
  spotlight point_at <0, 1, 0> radius 45 falloff 90
}

box
{ -<9, 11, 9>, <9, 11, 9>
  pigment { rgb 1 }
}

plane
{ y, 0
  pigment { checker rgb 0.05 rgb 1 }
}

intersection
{ quadric { <1, 0, 1>, <0, 0, 0>, <0, 1, 0>, -1 }
  cylinder { 0, y, 1 }
  pigment { green 0.5 }
  translate <-1.25, 1, 0>
}

intersection
{ quadric { <1, 0, 1>, <0, 0, 0>, <0, 1, 0>, -1 }
  cylinder { -y, y, 1 }
  pigment { green 0.5 }
  translate <1.25, 1, 0>
}

On the right side, there should have been a cylinder capped with a paraboloid. A thread has been started in povray.bugreports. Jerome has started to look at it.

Subsurface scattering must be made radiosity-aware.

Adjusting the brightness of an image-mapped sky sphere, although not an uncommon task especially when using HDR light probes, currently is cumbersome at best, as it is not possible to specify a “finish { ambient ... }” statement.

To simplify tuning a sky sphere’s brightness, I suggest introducing a “brightness FLOAT” modifier (defaulting to 1.0) to either the sky_sphere block or (as a more versatile solution) the image_map statement.

The Rect data type needs to be renamed to avoid a clash with a Mac OSX declaration. It was originally called Rectangle, but this clashed with a Windows declaration. Something more POV-specific should be used, e.g. PovRect.

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

Adding an AOI pattern is asked for fairly frequently.

In unix distribution these scripts

• allscene.sh
• allanim.sh
• porfolio.sh

have the variable VERSION set to 3.6

The parser is missing extra period characters when it parses a float as a vector component.

#local sample = <0.0.0.1,0,0>;

Doesn’t generate an error, but should.

The commands:

povray +i /home/ronis/Nm=500/povray.00001.pov

or

povray +i/home/ronis/Nm=500/povray.00001.pov

fail with: povray: this pre-release version of POV-Ray for Unix expires in 2 day(s) and 1 hour(s)
Failed to parse command-line option

Going to the directory and simply running: povray +i povray.00001.pov
works.

I came across this by accident trying to get emac’s povray mode to work; apparently it passes the full path name to povray.

I don’t think there is a problem in 3.6.1

After a recent update on the POV-Wiki the GuMax skin doesn’t recognize MediaWiki:Common.css entries.

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

In POV-ray 3.7 beta 33 under Windows XP, the editor’s MRU list incorrectly handles files that have a comma in the pathname. Only the part of the name before the comma appears on the MRU list, but the rest of the name is left off.
Consequently, the file cannot be reopened via the MRU list. The file is also not reopened on launch if pov was closed with the file open. This also occurs in 3.6.1, I haven’t tried it under 3.6.2 yet.

Interestingly enough, a quick peek in the registry shows that both 3.6 and 3.7
are saving the entire path name correctly under HKEY_CURRENT_USER\Software\POV-Ray\v3.6\POV-Edit\Recent (or \v3.7\POV-Edit\Recent).

This seems to be limited strictly to the editor’s MRU list. The file can still be opened normally using the open dialog box. Calling POV-ray from the command line and using a file or path name with commas in it works correctly. Included files with commas in the path work correctly, and the Tools→Edit last rendered file/View last rendered file work correctly also.

To duplicate, save a file with a comma in the pathname (either in the directory
name or the filename itself). Close the file, then attempt to reopen it using the MRU list in the file menu.

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.

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
}