The Persistence of Vision Raytracer (POV-Ray).

This is the legacy Bug Tracking System for the POV-Ray project. Bugs listed here are being migrated to our github issue tracker. Please refer to that for new reports or updates to existing ones on this system.


FS#65 - Add support for vectors with functions

Attached to Project: POV-Ray
Opened by Christoph Lipka (clipka) - Sunday, 08 November 2009, 01:38 GMT
Last edited by William F Pokorny (wfpokorny) - Thursday, 19 January 2017, 14:31 GMT
Task Type Feature Request
Category Backend → Parser/SDL
Status Tracked on GitHub
Assigned To No-one
Operating System All
Severity Low
Priority Normal
Reported Version 3.70 beta 34
Due in Version Future release
Due Date Undecided
Percent Complete 0%
Votes 0
Private No


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

This task depends upon

Comment by Thorsten Fröhlich (thorsten) - Monday, 11 January 2010, 10:25 GMT
  • Field changed: Task Type (Possible Bug → Feature Request)
  • Field changed: Category (Documentation → Parser/SDL)

The request is difficult to implement with the current code as it was never meant to be as universally useful as it turned out to be. The solution will have to be part of the 4.0 parser rewrite, and one good option will be to base the new function parser on llvm.

Comment by Simon (infoised) - Thursday, 21 February 2013, 17:10 GMT

If there is a parser rewrite in the future, functions returning vectors/colors could also be implemented (vectors as input are easily separated into components already, but functions returning vectors are now almost inexistent). A standing workaround is
function { pigment { function {} color_map{} }}
which is ugly.

Such functions would simplify all existing syntax. Splines actually already behave as vector-valued functions of one parameter. Now, one could also specify parametric curves (vector-valued functions with 1 parameter), parametric surfaces (2 parameters) or patterns (3 parameters), or more parameters, if you need more variables. One could then have

parametric {

v_function { my_function(u,v) }
translate my_other_function(parameter1,parameter2)
texture {
   pigment {
      v_function { my_color_function(x,y,z) }
   normal {
      v_function { my_normal_function(x+y+z,0) }


This would also enable using pigments and functions interchangeably: users could define their own color patterns, or use existing patterns as functions (now this is patched through builtin functions in "functions.inc"). The vector-valued functions could provide a one-shot solution for displacement warps, normal maps (they would be normalized first by the code), or other

Is there any particular reason that patterns and functions are now treated differently by povray?

Comment by William F Pokorny (wfpokorny) - Thursday, 19 January 2017, 14:31 GMT
  • Field changed: Status (New → Tracked on GitHub)

Now tracked on github as issue #190.