POV-Ray

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

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.

parser fails to report when an illegal map_type is used. For example map_type 10 and map_type 100 doesn’t produce an error

When running make on Linux, the backend source files (and possibly others?) are apparently compiled twice: first from the .../source/backend/ directory, and another time from the .../source/ directory. As an example, here are the corresponding lines for sphsweep.cpp:

g++ -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../../source -I../../source -I../../source/base -I../../unix -I../../vfe 
-I../../vfe/unix -pthread -I/usr/include/OpenEXR    -pthread -I/usr/include  -pipe -Wno-multichar -Wno-write-strin
gs -fno-enforce-eh-specs -s -O3 -ffast-math -pthread -MT sphsweep.o -MD -MP -MF .deps/sphsweep.Tpo -c -o sphsweep.
o `test -f 'shape/sphsweep.cpp' || echo './'`shape/sphsweep.cpp

g++ -DHAVE_CONFIG_H -I. -I..  -I.. -I../source/backend -I../source/base -I../source/frontend -I../unix -I../vfe -I.
./vfe/unix -pthread -I/usr/include/OpenEXR    -pthread -I/usr/include  -pipe -Wno-multichar -Wno-write-strings -fno
-enforce-eh-specs -s -O3 -ffast-math -pthread -MT sphsweep.o -MD -MP -MF .deps/sphsweep.Tpo -c -o sphsweep.o `test 
-f 'backend/shape/sphsweep.cpp' || echo './'`backend/shape/sphsweep.cpp

This is especially annoying on platforms that are rather slow at compiling.

The following scene has four spheres with different pigment color & filter settings:

- Left: filter 1
- Right: filter 0

- Top: red 0.0 green 0.5 blue 1.0
- Bottom: red 0.00 green 0.05 blue 0.10 (10% of the above)

Background is set to black, so that we only see the diffuse component of the object’s effective color.

Theoretically, both left spheres should be invisible, as they are fully transmissive (with a filtering effect), but apparently with a high filter setting, reducing an object’s pigment color actually increases the object’s effective diffuse color.

//+w600 +h600

global_settings{ assumed_gamma 1.0 }

camera {
  orthographic
  location  <0,0,-10>
  right 4*x
  up 4*y
  look_at   <0,0,0>
}

light_source{<10,10,-10> color rgb 1 parallel }

background { color rgb 0 }

default {
  finish {
    ambient 0
    diffuse 1
    specular 0
    phong 0
    reflection { 0.0 }
  }
}


sphere { <-1, 1, 0>, 0.8 texture { pigment { color rgb <0,0.5,1.0> filter 1.0 } } }
sphere { < 1, 1, 0>, 0.8 texture { pigment { color rgb <0,0.5,1.0> filter 0.0 } } }

sphere { <-1,-1, 0>, 0.8 texture { pigment { color rgb <0,0.5,1.0>*0.1 filter 1.0 } } }
sphere { < 1,-1, 0>, 0.8 texture { pigment { color rgb <0,0.5,1.0>*0.1 filter 0.0 } } }

This bug has been around in 3.6 already.

When using fade_distance and fade_power in combination with area_illumination, the light source fading is not applied to materials with subsurface scattering; see the following code for an example:

#version 3.7;
global_settings {
  assumed_gamma 1.0
  mm_per_unit 10
  subsurface { samples 200,20 }
}

camera {
  right x*image_width/image_height
  angle 30
  location  <0,1.5,-4>
  look_at   <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>]
    }
  }
}

plane {
  y, 0
  texture {
    pigment {
      checker
      color rgb <1.0, 0.8, 0.6>
      color rgb <1.0, 0.0, 0.0>
      scale 0.5
    }
  }
}

light_source {
  <50,50,50>
  color rgb 30
  area_light 5*x,5*y,17,17 adaptive 1 jitter circular orient
  area_illumination on
  fade_distance 10
  fade_power 2
}

cylinder {
  <0,0,0>, <0,0.2,0> 1
  texture {
    pigment { color rgb 1 }
    finish {
      ambient 0
      diffuse 0.7
      specular albedo 0.3
      reflection { 0.3 fresnel }
      conserve_energy
      subsurface { translucency 0.1 }
    }
  }
  interior { ior 1.5 }
}

sphere {
  <0,0.4,0>, 0.2
  texture {
    pigment { color rgb <1,0.6,0.0> }
    finish {
      ambient 0
      diffuse 0.0
      specular albedo 0.8 metallic
      reflection { 1.0 metallic }
      conserve_energy
    }
  }
}

Thread safety issue in functions using splines. 3.7.0.RC7.

First vetting in p.bugreports where several users were able to reproduce the fail on the following systems:

1) Ubuntu 12.1 i7 920 using 3.7.0.RC7
2) Ubuntu 12.04, AMD 2431 CPU, Linux 3.2.0-45 kernel using 3.7.0.RC7 (g++ 4.6 @x86_64-unknown-linux-gnu)
3) POV-Ray 3.7.0.RC7 (icpc 13.1.0 @x86_64-unknown-linux-gnu)

 Intel(R) Xeon(R) CPU E5-2680 0 @ 2.70GHz

 uname -or
 2.6.32-279.14.1.el6.x86_64 GNU/Linux

 lsb_release -irc
 Distributor ID: CentOS
 Release:        6.3
 Codename:       Final

4) Confirmed with openSUSE 12.2.
5) Just to add to the system list: with Windows and a core i7 one yields the same result.
6) “Le_Forgeron” ran under Intel Inspector (XE 2013) and provided this feedback :

 ...
  that might be less than 60 seconds, but with Intel Inspector (XE 2013),
 it becomes 42:50 (just 14 data races, oh well, that's just so friendly).

 ID  Type Sources Modules State
 P1  Data race isosurf.cpp; mutex.hpp povray New
 P2  Data race mutex.hpp; povms.cpp povray New
 P3  Data race povray.cpp povray New
 P4  Data race povray.cpp povray New
 P5  Data race mutex.hpp; pov_mem.cpp; splines.cpp povray New
 P6  Data race mutex.hpp; pov_mem.cpp; splines.cpp povray New
 P7  Data race mutex.hpp; pov_mem.cpp; splines.cpp povray New
 P8  Data race recursive_mutex.hpp; scene.cpp; task.cpp; taskqueue.cpp;
 view.cpp povray New
 P9  Data race condition_variable.hpp; vfe.cpp; vfesession.cpp povray New
 P10  Data race condition_variable.hpp; unixconsole.cpp; vfesession.cpp
 povray New
 P11  Data race condition_variable.hpp; unixconsole.cpp; vfesession.cpp
 povray New
 P12  Data race unixconsole.cpp; vfesession.cpp; vfesession.h povray New
 P13  Data race unixconsole.cpp; vfesession.cpp povray New
 P14  Data race [Unknown]; unixconsole.cpp; vfesession.cpp
 libboost_thread.so.1.49.0; povray New

 Numbers 2, 3, 4, 8, 9, 10, 11, 12, 13 & 14 are related to the handling
 of session (and occur once or twice only, excepted #8, four times).

 Number 1 is about isosurface (adjusting gradient at isosurf.cpp:1099 vs
 1098 (testing its value), and copying the isosurface) (IMHO, rendering
 threads updating the object... not the best move without some
 atomic/protection (and not sure a DBL is/can be atomic)) (occurs 2505
 times).

 Number 5, 6 and 7 are about splines
 * sp->Cache_Type & Cache_Point, splines.cpp :803 vs :814/815 (2024 times)
 * sp->Cache_Valid, :805 vs :813 vs :904 (1770 times)
 * sp->Cache_Data, :807 vs :903 (5025 times)

 Only my 0.02¢ (yes, very cheap), but it seems to confirm

For test code see attached files or SplineThreadSafety.pov attachment to
p.bugreports and images were posted to p.b.images.

Issue shows up any time more than one thread is used. Use of AA tends to hide
the problem so do not use it if using the output image for testing.

Thanks.
Bill P.

Using an end value of 1048576 or larger in a #for loop will cause the last iteration to be skipped, as can be demonstrated by the following code:

#declare N = 2000000;
#debug concat(”N = “,str(N, 0,50),”\n”)
#debug concat(”N-5 = “,str(N-5,0,50),”\n\n”)
#for (I, N-5, N, 1)

#debug concat("I   = ",str(I,0,50),"\n")

#end

(The limit was observed with a Win64 build; other builds may exhibit other limits or might even work fine, depending on the floating point engine used.)

As this limit is still far below the numeric precision limit, and a corresponding #while loop works fine with much higher values, this must be considered a bug rather than an inevitable limitation.

The bug can be tracked down to a faulty condition in tokenize.cpp, Parser::Parse_Directive(), CASE(END_TOKEN), case FOR_COND:

    if ( ((Step > 0) && (*CurrentPtr >= End + EPSILON)) ||
         ((Step < 0) && (*CurrentPtr <= End - EPSILON)) )

which should instead be:

    if ( ((Step > 0) && (*CurrentPtr > End + EPSILON)) ||
         ((Step < 0) && (*CurrentPtr < End - EPSILON)) )

In unix distribution these scripts

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

have the variable VERSION set to 3.6

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?

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

Bounding box computation for CSG intersection appears to be broken when one member is an arbitrarily transformed plane.

POV-Ray 3.6.2 has the same problem (can’t test for 3.6.1).

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

It appears that reflective bounces from blobs are
not incrementing the trace level, causing self-
reflecting hall of mirror portions to stall renders.

Trace level is not handled properly with blobs using per-component reflective or refractive textures, leading to lockups. Stepping through the code, it seems that POV-Ray fails to properly mark the blob object as increasing the trace level.

(Until this bug is fixed, the issue can be worked around in most cases by assigning a reflective texture to the blob as a whole.)

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

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.

Cone is not on good place when first base point is lower then end cap point.
Example:

cone { <0, 0, 0>, 2, <0, 1, 0>, 1 } - good
cone { <0, 0, 0>, 1, <0, 1, 0>, 2 } - bad

This is on 3.7 beta 35 version.

The #switch directive isn’t parsing correctly. In the following construct NO warning or error is generated:

#switch (RF)

case (0)
	rotate z*355
#break
case (144)
	rotate z*7.5
#break
case (216)
	rotate z*5
#break

#end

RF is a variable passed to the macro in which this construct resides. The first ‘case’ action IS executed, but none of the others are on successive calls to the macro. If I properly add ‘#’ to the second case the 1st and 2nd condition are executed but not the last. If ‘#’ is REMOVED from any of the break directives an error is generated and parsing halts.

Mosaic preview display didn’t work as expected, given these command line options: +sp64 +ep16. The preview was solid colored instead of the coarse preview that you’d expect.

I’ve tested a fix to unix/disp_sdl.cpp from clipka and it appears to work.

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
}

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 .

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

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

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

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

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.

A pigment statement not wrapped in a texture statement does not properly override a pigment previously defined for the object. In the following SDL code:

  #declare PLANE = plane { y,0
    texture {
      pigment { checker color rgb 1 color rgb 0 scale 0.1 }
  } }
  object { PLANE
    pigment { checker color red 1 color blue 1 scale 1.0 }
  }

the scaling of the pigment previously specified for the PLANE object is retained for the new pigment. Compare:

  #declare PLANE = plane { y,0
    texture {
      pigment { checker color rgb 1 color rgb 0 scale 0.1 }
  } }
  object { PLANE
    texture {
      pigment { checker color red 1 color blue 1 scale 1.0 }
  } }

which behaves as expected.

The issue has been around at least since POV-Ray 3.6.2.

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.

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.

Currently neither of these pages:

  http://www.povray.org/documentation/view/3.7.0/253/

  http://www.povray.org/documentation/view/3.7.0/90/

mention that the background can be transparent. Any normal user will try to give “background { ... }” a transparent color, see that it doesn’t work, and assume that POV-ray can’t do it.

The pages should mention the +UA command-line option, which enables the transparency.

I cannot edit any pages on wiki.povray.org, even after confirming my e-mail address.

This means that I cannot add any documentation, help improve the documentation, fix errors or help in any other way.

If you want contributions to the documentation, you should let users edit pages.

From synthetic post of Cousin Ricky in p.beta-test, 2013-06-24 circa 3:19 pm (MST)

William F Pokorny anonymous@anonymous.org wrote:
> It seems to be the case the gradient warnings are only generated if the
> isosurface is naked. If it is wrapped in an object as was the case with
> my thread safety example, we get no warnings.

Confirmed. If only I still had the concentration required to investigate
computer code.

#version 3.7;

#ifndef (MG) #declare MG = 40/9; #end
#ifndef (Naked) #declare Naked = no; #end

global_settings
{ assumed_gamma 1
  radiosity {} //force isosurface calculations from all directions
}

light_source { <-3.3125, 7.6250, -5.7374>, rgb 1 }

camera
{ location <0.0000, 1.0000, -5.6713>
  look_at <-0.7969, 1.2000, -0.0598>
  angle 10.7447
}

#include "functions.inc"

#if (Naked)
  isosurface
  { function { f_sphere (x, 0, z, (2660 - 40*y) / 9) }
    contained_by { box { <-80, 31, -24>, <-128, 56, 24> } }
    max_gradient MG
    pigment { rgb <1, 0.75, 0> }
    scale 1/128
    rotate -35 * x
    translate y
  }
#else
  #declare Test = isosurface
  { function { f_sphere (x, 0, z, (2660 - 40*y) / 9) }
    contained_by { box { <-80, 31, -24>, <-128, 56, 24> } }
    max_gradient MG
    pigment { rgb <1, 0.75, 0> }
    scale 1/128
    rotate -35 * x
    translate y
  }
  object { Test }
#end

On the command line, try:

declare=MG=1 declare=Naked=1

and

declare=MG=1 declare=Naked=0

To lose the warning, I had to declare the isosurface. Just wrapping the naked
isosurface in an object{} generated a warning.

Further analysis

if((Stage == STAGE_SHUTDOWN) && (mginfo->refcnt == 0))

I’ve recently been working with the netpbm ppm format and I have hit what I believe to be a bug in the way ppm files are read – very likely a bug in all netpbm formats. I am aware of the long standing povray issue with the netpbm file formats header where the height and width need to be on the same line as the magic number though that is not a requirement of the official format. This bug is different.

Namely in working with a larger number of ppm files I hit cases where a few would fail with the message : “Possible Parse Error: Unexpected EOF in PPM file” though the ppm files are fine. What is happening is that the first byte of data after the line feed (LF) (Ubuntu linux 12.04) happens to have a carriage return (CR) value.

The code which is set up to interpret the netpbm headers is reading a lines with “file→getline (line, 1024);” and this line reading code is pulling in the first byte of data with the CR value as part of the line. When the read by binary data, 8 or 16 bits at a time, starts, the povray read code is offset into the data by one byte too many.

The result from 10,000 meters, if input values were completely random file to file, would be netpbm read fails for size that make no sense in 1/256 files. In practice & depending on data some might never see fails while an unfortunate few might almost always fail.

I’d make some argument any CR following a LF character should not be pulled in as part of the line read even on windows/dos systems where CRLF is the usual line termination order. I think though the real fix is better netpbm header reading code which more strictly breaks apart the header on the first whitespace character doing the last depth break, aware of the file size, so it can decide what portion of any valid sequence of whitespce characters after the decimal depth value is data and not whitespace.

The attached tarball when unpacked has both a passing and failing case. To run “povray fails.pov” or “povray works.pov”. The only difference between the two ppm files if the fails.ppm data is all 0x0D while works.ppm data bytes are all 0x0C. The image rendered is meaningless.

Thanks for your time.
Bill P.

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”