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#263 - Functions and patterns for finish variations

Attached to Project: POV-Ray
Opened by Simon (infoised) - Saturday, 22 December 2012, 04:46 GMT
Last edited by William F Pokorny (wfpokorny) - Tuesday, 24 January 2017, 14:37 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 RC6
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No


the pigment {} and normals {} sections allow spatial variation of color, transparency and normal map. On the other hand, the specular parameter is a fixed scalar. This removes many possibilities. For instance, specularity could vary in space (speckles of oil or water on a surface, worn-out finish, having specularity reduce where the pigment transparency increases) and have color components. With current settings, the light’s color is simply multiplied by the scalar specified by “specular”, whereas multiplying each component with different color could create diverse effects (the “metallic” keyword already acts similar to duplicating the specular color from the pigment). The syntax could be exactly the same as for the pigment (all the patterns, color maps, image maps and functions would apply, allowing reuse of most of the code).

The effect can now be partially faked by having patterned textures, but it requires a very complex code and the lack of layering of patterned textures makes it difficult to vary the specularity and pigment separately.

In a similar way, roughness and brilliance could also vary in space.

Doing the same for varying reflectivity would be more difficult, as it has angular dependence and possibilty of Fresnel calculation, but it could at least be a full color instead of a simple scalar multiplier. For instance, having a blue surface that reflects only red component of the light should not be impossible.

I think at least part of this functionality actually makes the scene description language more uniform and self-consistent.

This task depends upon

Comment by Grimbert Jérôme (Le_Forgeron) - Saturday, 22 December 2012, 21:26 GMT


Is it some kind of finish_map ?
( http://www.povray.org/documentation/view/3.6.2/82/ )

(Finish_map do not exists, but the documentation suggests using texture_map instead)

What about, for finish, to use a top layer with a transparent pigment (for all entries of texture_map) and next layers (which do not have finish) with actual pigments ?

I do not get "the lack of layering of patterned textures".

Comment by Simon (infoised) - Sunday, 23 December 2012, 23:24 GMT

I want something like this:
texture { base texture
grass-like texture, no specularity
texture {
snowy icing on the mountain, but without making the grass shiny
gradient z
texture_map {
[0 pigment { transparent } finish { specular 0 } ]
[1 pigment { color White } finish { specular 1 } ]

But this does not parse, because apparently, a texture_map cannot be layered with a regular one:
"Parse Error: Cannot layer a patterned texture over another."

I do believe I could write even more complicated composite pigments to combine all this into one single texture map, but nonetheless, I think that making "specular" having color and position-dependence would be a very useful feature with obvious syntax, and quite easy to implement, as retrieving the color would be exactly the same as with pigment { } statement. It could be done so that

specular [single number]

would work as usual
but a curly-brace block

specular {

pattern or color or function
[optional color_map]
[optional transformations (scale,translate,rotate,turbulence)]


would work with explained functionality, without breaking backward-compatibility. In this extended syntax, the roughness and brilliance could be included inside the block, as they belong to the specularity calculation anyway, as well as the "metallic" keyword, although it is quite unnecessary in this context, because you can specify the color of the reflection on your own. Including "type" keyword could also switch from phong to specular, unifying the entire specularity formalism in one block and allow future addition of other specularity algorithms that have different dependence on input and output angle, or include anisotropy.

I realize that new features are not a priority, but I hope you consider this a possible future extension, as it would allow creation of more naturally-looking materials (greasy glass, fingerprints, varying wetness of surfaces, worn-out varnish).

Comment by William F Pokorny (wfpokorny) - Tuesday, 24 January 2017, 14:37 GMT
  • Field changed: Status (Unconfirmed → Tracked on GitHub)

Now tracked on github as issue #218.