POV-Ray

Being able to have functions operate on vectors would be pretty nice to have.

User-defined warps would be nice to have, something along the lines of:

warp {
  function { MyFnX(x,y,z) } // function to compute pattern-space x-coordinate from object-space <x,y,z> coordinate
  function { MyFnY(x,y,z) } // ditto for pattern-space y coordinate
  function { MyFnZ(x,y,z) } // ditto for pattern-space z coordinate
}

// a displacement warp:
warp {
  function { x + MyFnX(x,y,z) }
  function { y + MyFnY(x,y,z) }
  function { z + MyFnZ(x,y,z) }
}

The following scene gives a comparison of current conserve_energy handling in standard shadow computations vs. photons.

Note how the rather highly reflective slabs fail to cast shadows, except where the photons target sphere enforces computation of shadow brightness to be done by the photons algorithm.

For more realistic shadowing without the need to enable photons, I suggest do add proper conserve_energy handling to the shadow computation code (which shouldn’t be too much effort).

global_settings {
  max_trace_level 10
  photons { spacing 0.003 media 10 }
}

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

light_source {
  <500,300,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 0.7 } }
}

#declare M_Glass=
material {
  texture {
    pigment {rgbt 1}
    finish {
      ambient 0.0
      diffuse 0
      specular 0.2 // just to give a hint where the sphere is
    }
  }
  interior { ior 1.0 }
}

#declare M_PseudoGlass=
material {
  texture {
    pigment {rgbt 1}
    finish {
      ambient 0.0
      diffuse 0.5
      specular 0.6
      roughness 0.005
      reflection { 0.3, 1.0 fresnel on }
      conserve_energy
    }
  }
  interior { ior 1.5 }
}


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

// behind target object
box {
  <-0.2,0,-2.3>, <0.0,4,0.3>
  material { M_PseudoGlass }
  rotate z*1 // just to better see the reflection of the horizon
}

// before target object
box {
  <2.4,0,-2.3>, <2.6,4,-0.3>
  material { M_PseudoGlass }
  photons { pass_through }
  rotate z*1 // just to better see the reflection of the horizon
}

The combination of metallic reflection with conserve_energy causes the reflection to lose colour, as demonstrated by the following scene:

global_settings {
  max_trace_level 10
}

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

light_source {
  <500,300,150>
  color rgb 1.3
}

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

#declare M=
material {
  texture {
    pigment {rgbt <1.0,0.7,0.2,0.99>}
    finish {
      ambient 0.0
      diffuse 0.5
      specular 0.6
      roughness 0.005
      reflection { 0.8, 1.0 metallic }
      conserve_energy
    }
  }
  interior { ior 1.5 }
}

box {
  <-0.2,0,-2.3>, <0.0,4,0.3>
  material { M }
  rotate z*5
  rotate x*2
}

The SDL currently provides no way to compute the exact direction of a spline at a given location, even though mathematically this is a piece of cake: The first-order derivative of any spline section gives you the “speed” as a vector function, and is trivial to compute for polynomial splines (which are behind all spline types that POV-Ray supports); the normalized “speed” vector, in turn, gives the “pure” direction.

For exact direction/speed computations, I propose to extend the SDL invocation syntax as follows to allow for evaluating a spline’s derivative:

    SPLINE_INVOCATION:
        SPLINE_IDENTIFIER ( FLOAT [, SPLINE_TYPE] [, FLOAT] )

or

    SPLINE_INVOCATION:
        SPLINE_IDENTIFIER ( FLOAT [, FLOAT] [, SPLINE_TYPE] )

where the second FLOAT will specify the order of derivative to evaluate (defaulting to 0). In order to compute the position, direction, and acceleration of an object traveling along a certain spline, one could then for instance use:

    #declare S        = spline { ... }
    #declare Pos      = S(Time);
    #declare VSpeed   = S(Time,1);
    #declare VAccel   = S(Time,2);
    #declare Dir      = vnormalize(VSpeed);
    #declare Speed    = vlength(VSpeed);
    #declare AccelDir = vnormalize(VAccel);
    #declare GForce   = vlength(VAccel) / 9.81;

Alternatively, a mechanism may be devised to create a spline representing another spline’s derivative; however, it would be debatable whether the syntax should be parameter-like (being an added information that could be overridden again when creating other splines from such a derived spline), or operation-like (converting the spline), and in the latter case how it should affect spline type (and consequently control points); so the spline invocation parameter approach might be more straightforward, with less potential surprises for the user.

I observe frequent segfaults with POV-Ray 3.7 betas when rendering scenes using photons:

• Debian Linux 4.0r5 “etch” for AMD64
• AMD Phenom X4 9650 2.3GHz, 6 GB RAM
• POV-Ray compiled with Intel icpc 11.0

Segfaults are sporadic but frequent (occurring in roughly 50% of all photon renders).

Code inspection shows that we’re still using fseek() and ftell() in various places (including text file input), which can’t handle file positions of 2GB and beyond (except on 64-bit linux machines); those calls need to be examined and (where appropriate) replaced with the fseek64() macro we’re already defining (but currently not using), and a to-be-defined ftell64() macro.

One potential (untested) error scenario would be a scene file calling a macro that is defined at the end of a > 2GB long include file.

When using cutaway_textures in a CSG object that has union children, results are not as expected; instead, surfaces in the union children that have no explicit texture will be rendered with the default texture instead. This is not the case for e.g. difference children.

Example:

#default { texture { pigment { rgb 1 } } }

camera {
  right x*image_width/image_height
  location  <0,1.5,-4>
  look_at   <0,1,0>
}

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

#declare U = union {
  sphere { <0,-0.1,-1>, 0.3 }
  sphere { <0, 0.1,-1>, 0.3 pigment { color red 1 } }
}

intersection {
  sphere { <0,0,0>, 1 pigment { color green 1 } }
  object { U }
  cutaway_textures
  rotate y*90
}

When declaring U as an intersection instead, the results are as expected, with the surface of the first sphere in U being rendered with the texture defined in the outer intersection.

When a command-line parameter in an .ini file cannot be parsed (such as “+a.3”), POV-Ray reports a “Problem with setting”, quoting the command line, rather than indicating that the problem occurred in an .ini file. This leads the user to think that the problem is with the command line itself, unnecessarily confusing him.

Just like radiosity load/save, the photon mapping load/save mechanism should be moved to the frontend and controlled via command-line switch, instead of being SDL-driven in the backend.

For proper render abort/continue support, radiosity cache data must be written to (or read from) disk even if the user does not explicitly opt to have a sample data file written/read. This feature has temporarily been dropped from 3.7 beta and is still pending re-implementation.

To meet high-reproducibility requirements in conjunction with SMP operation, it may be necessary to extend the 3.6 radiosity cache file format.

Windows UI code should be refactored to use _TCHAR throughout instead of char, as well as the corresponding string function macros, to head for Unicode support.

Subsurface Scattering still uses its own rudimentary code to compute illumination from classic light sources; this must be changed to use the standard light source & shadow handling code, to add support for non-trivial light sources (e.g. spotlights, cylindrical lights, area lights), partially-transparent shadowing objects etc.

Subsurface scattering must be made photon-aware.

Near concave edges, radiosity samples may be re-used at a longer distance away from the edge than towards the edge; there is code in place to ensure this, but it only works properly where two surfaces meet roughly rectangularly, while failing near the junction of three surfaces or non-rectangular edges, potentially causing “cross-talk”.

It should be investigated how the algorithm can be improved or replaced to better cope with non-trivial geometry.

Some features are optional in custom builds of POV-Ray (I’m thinking about OpenEXR in particular); it would be nice to have a syntax for an SDL script to check for support of such features, so it may take some fallback action if the feature is not supported.

Most sample scenes and include files were designed at times when POV-Ray did not to any proper gamma handling, or still used the inferior 3.6 “assumed_gamma” mechanism.

All the scenes and include files should be reviewed, and updated to fit the new 3.7 gamma model.

The primary task will probably be gamma-adjusting literal color values and ambient parameters; I suggest using macros (which ideally should be defined in an include file) to be set according to the #version statement, so the scene/include file could be kept compatible with older versions.

With previous versions of POV-Ray, it was possible to turn off display output, but still assess the output during render by viewing the output file as it was progressively generated. This allowed e.g. to run a long render on a remote machine as a background process, and check the output from time to time via FTP or similar.

The syntax notation used in the main documentation is different than that used in the quick-reference section. This should be changed for consistency, using the superior quick-reference notation throughout.

In the photons map, the direction of each photon is stored as separate latitude & longitude angles (encoded in one byte each), causing the longitudinal direction component’s precision to be unnecessarily high for directions close to the “poles” (Y axis); in addition, encoded value -128 is never used. For better overall precision as well as precision homogenity, the following scheme could be used instead:

• Encode the latitude (-pi/2 to +pi/2) into LatCount=226 distinct values (= 256*sqrt(pi)/2) rounded to the next even number) from 0 to LatCount-1 using

latCode = (int)((LatCount-1) * (lat/M_PI + 0.5) + 0.5)

• For each latitude code, define a specific number of encodable longitude values, LngCount[latCode] = approx. cos(lat)*pi*65536/(2*LatCount); this can be a pre-computed table, and may need slight tweaking for optimum use of the code space. Encode the longitude (-pi to +pi) into a value from 0 to (LngCount[lat]-1) using

LC = LngCount[latCode];
lngCode = (int)(LC * (lng/(2*M_PI) + 0.5) + 0.5) % LC;

• Besides LngCount[latCode], also store the sum of LngCount[i] with i < latCode as LatBase[latCode]; encode the direction as

dirCode = LatBase[latCode] + lngCode;

• For decoding, a simple lookup from a precomputed list of directions could be used (2^15 entries, i.e. one hemisphere, will suffice). To conserve space, direction vectors could be scaled by (2^N-1) and stored as (N+1)-bit signed integer triples rather than floating point values; due to the limited precision of the lat/long information, 8 bits per coordinate might be enough, giving a table size of 96k. A full double-precision table would require 786k instead.

Front- & Back-end code should be refactored for full Unicode support in scene files and strings.