POV-Ray

Reflective texture maps can cause a stack overflow crash.

sphere{0,1
  texture{
   bozo
   texture_map{
    [0 pigment{rgb 0}]
    [1 pigment{rgb 0} finish{reflection 1}]
   }
  }
}

Array.inc and subsurface.pov are in read only mode, they probably should have normal permissions.

Beta 32, compiled from source on Linux/Ubuntu, amd64.

The random “window display lock” is back.
(as the previous “solution” was to get no window display usable, that’s not so bad).

What is it: sometime, when the rendering window is activated, povray just draw the frame
of the window, paint it black, does not display anything else but seems to perform the
rendering in separate threads. Whenever the mouse move over the frame of the window, it
unlock the updating process and big parts of the rendered image pop up.

What it is not fine: if you do not move the mouse over the window, povray will just stall.
This is more a problem for animation rendering, as getting the display might be a wanted
bonus to monitor the rendering images, and you just fall into that lock: your expected
night rendering could very well be suspended on the first frame.
Moreover, the “move the mouse over” works only for local display. In previous beta (not
yet checked with 32), with a remote display, there was no way to unlock povray.

Versions of POV-Ray prior to 3.7 had the ability to write the image output as a stream to STDOUT. This was particularly useful in unix as it allowed POV-Ray output to be directly piped to other processes.

The introduction of SMP and the associated non-linear generation of pixels complicates stream output to the extent that it is not currently available in v3.7.

At a minimum 3.7 must at least be able to write the completed image to STDOUT after a render - this is not an optimal solution but is better than nothing. Ideally however once entire lines are complete (most likely this will occur in batches due to the block nature of the render subdivision) these lines will be written immediately to STDOUT (after possibly being processed through the appropriate image format routines).

NB currently the image format routines are not invoked until the entire render is completed, so to do this would be a significant modification. However if we limit real-time stream output to “simple” non-compressed formats (e.g. PPM), it would not be overly difficult, and from the point of view of Unix-like operating systems (where the piping feature is most useful), if the data is in PPM format it can easily be transformed into anything else.

Function use in image maps is broken.

The following should result in a white and green checkered unit square, but is transparent.

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

background {rgb <1,1,1>}

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

plane {y,-1 pigment{checker rgb <1,0,0> rgb <1,0.5,0.5> }}

plane {y,-0.99 
 pigment {
  image_map { 
   function 10,10 { 
    pigment {checker rgb <0,1,0>, rgb <1,1,1> scale 0.1}
   }
   once 
  }
  rotate <90,0,0>
 }
}

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?

Recruit version 3.7 documentation editors from the users community.

The following files were garbled in changelist #4648 by stripping all line terminators, making the files unusable:

• .../scenes/advanced/cats/cattext.inc
• .../scenes/animations/life/blink4.inc
• .../scenes/animations/life/walker.inc

Line terminators of these files were already problematic in previous versions of the file, having been CR-only.

The following files changed with #4648 should be reviewed closely as well, as they were previously CR-only, too, and at least some of them exhibit some peculiarities regarding line and/or file terminators:

• .../scenes/animations/pentmap/pentmap.ini
• .../scenes/animations/pentmap/pentmap.pov
• .../scenes/animations/slinky/slnk.ini
• .../scenes/incdemo/metals/metals.doc
• .../scenes/incdemo/stones/stones.doc
• .../scenes/incdemo/woods/morewood.doc
• .../scenes/incdemo/woods/woods.doc
• .../scenes/textures/pigments/skies/skies.doc

Reported for freebsd 7.2 (current production version, true for previous version, unknown for 8.0 in beta now)

freebsd does not provide CLOCK_PROCESS_CPUTIME_ID
(even if CLOCK... is posix).

As a consequence, compilation of the unix-source is currently not possible for freebsd target.

Might be a simple selection for Change 4356 ?
(assuming a relevant test in ./configure)
(getrusage() seems available on freebsd, but does it provide the pieces of information needed, I do not know that code good enough to assert that)

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

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

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.

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

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
}

When rendering a series of scenes (e.g. animation, or render queue in POV-Ray for Windows), number_of_waves is not properly reset to its default value between scenes, causing the parameter to default to the value set by the previous scene.

For instance, rendering the following scenes from a queue will cause “arches.pov” to be rendered differently the second time:

1. scenes\textures\finishes\arches.pov
2. scenes\textures\normals\normavg.pov
3. scenes\textures\finishes\arches.pov (again!)

The parser does not accept mesh objects (or CSG objects including a mesh object) as a parameter to the inside() built-in function, reporting error “Solid object identifier expected”, even if the mesh is “solidified” by specifying an inside_vector.

(see news://news.povray.org:119/4a983716@news.povray.org)

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

Using a facet pattern in a normal map results in a unspecified error in Evaluate_TPat at the render stage.
This probably should be caught at parse time to give a more descriptive error and a line number.

Example:

sphere {
  0, 1
  texture{
    pigment{rgb <1,1,1>}   
    normal {
      facets
      normal_map {
         [0 bumps ]
         [0.5 facets ]
         [1 bumps ]
      }
    } 
  }
}

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
}

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

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

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.

In the following scene, the mesh object will always cast a fully-opaque shadow, even if the image has an alpha channel:

camera {
  location  <0.5, 1.0, -1.0>
  look_at   <0.5, 0.0,  0.5>
}

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

mesh {
    triangle { <0,0,0>, <1,0,0>, <1,0,1> uv_vectors <0,0>, <1,0>, <1,1> }
    triangle { <0,0,0>, <1,0,1>, <0,0,1> uv_vectors <0,0>, <1,1>, <0,1> }
    texture { pigment { uv_mapping image_map {png "FOOBAR.png"} } }
}

plane { y, -0.1 pigment { color rgb 1 } }

The following modification to the texture will give the expected results:

    texture { uv_mapping pigment { image_map {png "FOOBAR.png"} } }

The problem can be observed with both POV-Ray 3.7 (tested with beta.34), as well as 3.6 (tested with 3.6.2).

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

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.

In gif.cpp (source/base/image), circa line 150:

			case ',': /* Start of image object. Get description. */
				for (int i = 0; i < 9; i++)
				{
					if ((data = file->Read_Byte()) == EOF)
						throw POV_EXCEPTION(kFileDataErr, "Unexpected EOF reading GIF file");
					buffer[i] = (unsigned char) data;
				}

				/* Check "interlaced" bit. */
				if ((buffer[9] & 0x40) != 0)
					throw POV_EXCEPTION(kFileDataErr, "Interlacing in GIF image unsupported");

The loop reads the 9 bytes of the Image Block, but is testing the tenth byte for interlacing.

Reference for image format: http://www.onicos.com/staff/iz/formats/gif.html#ib

When the gif is generated by Gimp, the Image block is preceded by the comment block which default to “Created with GIMP”... the comment is read in the buffer, and the “i” will be in buffer[9], any letter after @ will indeed block povray.

This bug was not present in 3.1g nor in 3.6.1 (due to different source to handle gif).

If not created by Gimp, or with shorter comment, the content of buffer[9] is more random, yet it might trigger the bug depending on the previous blocks and their handling.