This is a combined bugfix patch which fixes the following problems (most of which were already present at 3.5). Patches were written by me unless stated differently.

• Fix parametric object getting completely black due to self-shadowing. Credit: Massimo Valenti
• Patch against out-of-bounds array indexing in parametric object code for too small accuracies. Accurary will now be reduced when the sector limit is reached.
• Isosurface accuracy improvement patch (see "manual patch" below).
• Isosurface warning patch (use floaing decimal point for accuracy values).
• Patch against vertex index typos in bezier bicubic patch code. Credit: Gianluca Arcidiacono
• Patch against media_attenuation bug (atmospheric effects). Credit: A. Brinkmann
• Some minor things.

This is a combined (bug)fix patch which includes the following things:

• Make POVRay exit with non-zero codes upon failure. This patch is required if you want to use RendView.

Grid pattern: Has similarities to a continuous checker pigment and available for planar and cylindrical mapping. Primary used to create grid textures using a half-transparent color map.

Syntax: grid followed by cylindrical or planar. Use frequency to control the number of repetitions of the cylindrical version.

Below is a sample image and the interesting part of the associated POV SDL code: (The full code is also available.)

cylinder { // blue cylindrical net 0, 0.17*y, 0.1 open pigment { grid_pattern cylindrical frequency 22 color_map { [0.2 rgb <0.3,0.3,1>] [0.2 rgbf 1 ] } // <-- transparent scale <1,0.01,1> // <-- tune mesh size } } box { // red planar net <-0.1,0,-0.1>, <0.1,0.001,0.1> pigment { grid_pattern planar color_map { /* like above */ } scale <1,1,1>/50 // <-- tune mesh size } rotate 90*x // <-- as grid plane is X+Z }

Full POV SDL code: grid_pattern-demo.pov

POVRay-3.6.1 has a built-in slope pattern which can be used to choose a color according to the slope, i.e. the value of the scalar product of the surface normal and a user-specified direction vector.
This patch adds a new pattern called radial_slope which works similarly, however the direction vector is the vector from the origin to the point where the pattern is evaluated. Hence, a sphere has always a radial_slope value of 1.

Syntax: Just like any other pattern without extra parameters.

An image made with the radial slope pattern can be seen here under the topic "Mars, slope color".
Below is a further sample image and the interesting part of the associated POV SDL code: (The full code is also available.)

isosurface { function { f_sphere(x,y,z,1.5)- f_noise3d(2*x,2*y,2*z)*0.7 } max_gradient 2.5 contained_by { sphere { 0, 2.3 } } pigment { radial_slope color_map { [0.6 rgb <1,0,0>] // steep hills [0.975 rgb <1,1,1>] [1 rgb <0,0,1>] // sphere-like } } scale 0.6 }

Full POV SDL code: radial_slope-demo.pov

Patch to improve accuracy of POVRay's isosurface object. Written to work against black spots showing up on some of my renderings. Details and some sample images.
Note: This (manual) patch is included in the general bugfix patch. (I consider it a bug when not using linear interpolation at the end of a bisection sequence.)

If you ever whished that POVRay would be so clever that it could paint the interesting parts of an image first and the not-so-interesting last, you should have a look at the progressive refinement patch.

It will trace those parts of the image which have large color variation first and furthermore allows you to manually select regions to be traced using the mouse. You get bilinearly interpolated "previews" instead of blocky mosaic preview and you may abort the render at any time saving the state as you see it.
The finally rendered image is the same image as with normal POVRay, just that you see more quickly what it is about. Very useful for scene design.. Read more...

POVRay's isosurfaces are very versatile objects because they allow to visualize the surface in space where an arbitrary user-supplied function in space has some threshold value (usually zero). Inside POVRay, the user functions are evaluated using a virtual machine which interpretes "compiled" assembly of the function which is generated automatically at parsing stage. This, however, is much slower than if the user function would actually be compiled for the real CPU/FPU.

This is why I wrote the just-in-time compiler patch for POVRay which allows to actually compile the user functions on-the-fly (with no manual user interaction!) using GCC to speed things up. Read more...