POV-Ray

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

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

I’ve been trying to upgrade povray 3.6.1 to 3.7-beta-32. I’ve configured with no additional arguments, and the configure dies with:

checking whether to build the boost thread library from sources... no
checking for boostlib >= 1.35... yes
checking whether the Boost::Thread library is available... yes
checking for exit in -lboost_thread... no
checking for exit in -lboost_thread-boost_thread... no
configure: error: Could not link against boost_thread-boost_thread !

I figured that the problem was with my boost installation (1.35) and upgraded boost to 1.39; the problem remains. I tried to see if exit was defined in libboost_thread and/or libboost_thread-boost_thread and it isn’t. Just to be sure that my currrent setup works for the released version, I rebuilt/reninstalled 3.6.1, which went without problem.

I’m on a slackware-12.2 box, using gcc-4.4.0.

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

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

For some particularly “heavy” SDL scripts, it might be desirable to override (or complement) the standard “Parsing 47110815K tokens” progress information with some more helpful custom info, e.g. “Planting trees... (37%)”, or “Generating terrain mesh row 47 of 500”.

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.

Linux beta 32, 64bits, compiled from sources.

povray -w800 -h600 +a0.3 +kfi1 +kff78
-L/usr/local/share/povray-3.7/scenes/incdemo
-Ii_internal.pov +WT5 +R4 +AM1 +MB1

Important issue: +WT5 +MB1

Seems Fine for +WT1 +MB1
Also fine for +WT5 +MB9

The intersection with the containing box displays some two-shades of grey
random checkered patterns.
Size of square looks like size of renderering thread. Position too.

Impacted frames (of 78):
01, 02, 03, 30, 48, 74, 76.

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.

3.6x only bug with easy/known fix. Error message: “Identifier expected, incomplete function call or spline call found instead.” caused by token counter variable using the wrong special value. The symptom occurs when using a lot of splines. See this thread for details.

(I am using a self-compiled special build because I use a lot of splines in 3.6 but would rather use an official 3.6)

In unix distribution these scripts

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

have the variable VERSION set to 3.6

Adding an AOI pattern is asked for fairly frequently.

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

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

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

Using trace or inside with a julia fractal causes a crash.

#declare Test = julia_fractal {
  <-0.083,0.0,-0.83,-0.025>
  quaternion
  cube 
  max_iteration 8
  precision 20
};
#declare Norm = <0,0,0>;
#declare Hit = trace(Test,<0,0,-10>,z,Norm);
#declare Center = inside(Test,<0,0,0>); 

Overlapping partially transparent objects can result in speckled shadows.
Rays shouldn’t leak through the coincident areas, they should return one
of the two textures. This was correct in 3.6.

#declare testmat = material { texture {
      pigment {color <1,0,0> transmit 0.5}
}};

camera { location  <1.0, 2.0, -4.0>
   direction 1.5*z
   right     x*image_width/image_height
   look_at   <1.0, -0.2,  0.0>
   angle 30 }

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

plane {y,-1 pigment{rgb <1,1,1>}}

union {
   sphere {<0.0,0,0>,0.5 material{testmat}}
   sphere {<0.1,0,0>,0.5 material{testmat}}
   sphere {<0.2,0,0>,0.5 material{testmat}}
   sphere {<0.3,0,0>,0.5 material{testmat}}
   sphere {<0.4,0,0>,0.5 material{testmat}}
   sphere {<0.5,0,0>,0.5 material{testmat}}
}

Files of exactly 4k length can cause a full crash exception when opened.

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

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.

Input image files may have been created with gamma pre-correction for some specific target gamma, which may vary from image to image. Some file formats like PNG or HDR support embedding gamma pre-correction information in the image file, but this information may be missing or faulty, and some formats don’t support it at all. Additionally, it may be desirable to tamper with an input image’s gamma for artistic reasons.

Therefore, I suggest adding a means to explicitly specify input images’ originally intended target gamma on a per-image basis, like:

image_map { jpeg "MyImage.jpg" assumed_gamma 1.8 }

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.

Subsurface scattering must be made radiosity-aware.

The version 3.6 documentation needs to be updated to suit the changes for version 3.7.

There are a number of problems with the Windows version of POV-Ray under Windows Vista. To resolve these, the setup program needs to be re-written and the location of internal files changed.

Beta 32 is failing to render a mesh2 smoothly on 64-bit XP - output shows flat triangles rather than smoothed triangles.
Issue is not present in 32-bit build.

Reported in http://news.povray.org/49e51489%241%40news.povray.org. Demo image rendered using standard chessmesh scene.