POV-Ray

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.

Attached to Project: POV-Ray
Opened by Christoph Lipka - 2009-11-08
Last edited by William F Pokorny - 2017-01-19

FS#65 - Add support for vectors with functions

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

Thorsten Fröhlich commented on Monday, 11 January 2010, 10:25 GMT

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.

Simon commented on 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?

William F Pokorny commented on Thursday, 19 January 2017, 14:31 GMT

Now tracked on github as issue #190.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing