With time I've compiled a list of features I would be happy to see in
POV-Ray. I think it wouldn't hurt if I posted it here.

: df3 tiling, map_type

The density_file pattern would benefit from the possibility to be
tiled in 3D, allowing for easy creation of 3D textures. Mapping types
different from planar would also be great. The former can be achieved
with a set of repeat warps but the seams become visible. The latter
may or may be possible with the proper warp in MegaPOV.

: df3 output, dfc file

The density_file pattern is overlooked by many people because .df3
files are not easily made. It's a pity because this pattern has great
possibilities. If POV were able to directly output to .df3 it would
make life easier for those of us who would like to explore these
possibilities.

My idea is that a new file type triggered by a comman-line (or INI)
option is introduced. An additional depth parameter to output
resolution has to be introduced, too. The program would then sample
the unit cube at width*height*depth points and save the clipped
brightness directly to a density file. Brightness should only be
affected by pigments and media density.

A new type of density file (for example dfc), one that stores
three-dimentional RGB data, would also be of use. The RGB data could
then be used as a default color map for the density_file pattern based
on this file if no color map is specified. Combined with df3 or dfc
output one could easily render a glowing media version of any object,
while preserving the colors.

: strict variable types

I've often fallen victim to implicit type promotion. Also, often I
need to store a large array of boolean data but it is internally
stored as double, taking up 8 or 10 times more memory. What I would
like to see are several variable types optionally assigned to a
variable upon declaration, namely signed/unsigned byte/char and int.
Vector types such as vector2d, vector3d, vector4d and vector5d would
also be useful when memory is an issue, as well as for stricter code.

Fot the non-programmers:

Variable type    Memory used      Range      Applications
--------------------------------------------------------------
unsigned char    1 byte           0 .. 255   counters, indices,
                                             large boolean arrays

signed char      1 byte         -128 .. 127  counters, flags

unsigned int     2 bytes         0 .. 65536  larger counters, indices

signed int       2 bytes     -32768 .. 32767 signed counters,
                                             discrete variables

: promotion

Promoting means converting a value to another type. For example,

#declare Foo = (vector3d) vlength (y)

would assign a vector, namely <1,1,1>, to Foo.

: hash variables

A hash variable is like an array but in addition to an index, each
element has a name by which it can be invoked. For example,
Posters[155] doesn't tell much while Posters[Peter_Popov] does, and
they mean the same to the parser. One useful feature is that they make
passing parameters to a macro much easier.

: media emission/absorption color map

A quick and dirty way to model certain volumetric effects is to map a
color map onto the total emission/absorption along a ray. The syntax I
have in mind is to add an optional color_map block after emission /
absorption.

: patterned turbulence, turbulence_map

Currently it is impossible to vary the turbulence of a pattern. A
blended pattern can not do that. Sometimes one needs to increase
turbulence in certain regions and decrease it in others. An optional
pattern and turbulence_map block after the turbulence keyword could
specify the behaviour of turbulence. More precisely, the value of the
turbulence pattern will be calculated (with the turbulence map in
mind) and will be used to scale the turbulence vector in that point.

: spotlight scale

Non-uniform scaling of spotlights would allow for elliptical
spotlights.

: polygonal spotlight

Although unrealistic, these have their applications. Combined with an
area light, they can be used to simulate, for example, light passing
through a window or keyhole or similar.

: better alpha channel support

The current alpha channel does not take into account media,
transparency and focal blur. There's also a lack of per-object alpha
channel control. For example of one wants to render a focal-blurred
reflective sphere on a checkered floor and then use only the sphere in
a paint program, one would have to make two renders, one for the image
and one for the alpha channel. And sometimes it is just not possible
to isolate the alpha-channel on a per-object basis.

: displacement mapping for patterns

Sometimes a very specific type of turbilence is needed, for example
twisting or waving or similar. A displace warp which takes a pattern
as a parameter and returns a vector based on the color on that pattern
in a point, namely x = r-0.5, y = g-0.5, z = b-0.5, would make such
things possible. Maybe some of the isosurface gurus can do it with
function pigments but I can not.

: chop pieces off with bounding

If a bounding object is smaller than what it bounds, the results are
unpredictable. I think a more logical behaviour would be the one seen
in isosurfaces, i.e. the bounding object should restrict the bounded
object, exposing the intersection surface and texture. Of course, it
would still bound the object for ray-shape intersection tests.

: leave original textures when CSGing

When performing a CGS difference or intersection, any object with a
non-specified texture is assumed to have a black pigment and ambient
0. I think a more reasonable behaviour would be to ignore its texture
and use the texture of whatever object the intersection point is in.
Of course this could lead to "coincident interiors" problems but I
think with proper CGSing they can be avoided.

: seeded randomness for area_light and aa jitter

This one is pretty straight-forward. It would make animation people's
lives easier.

: zero text object thickness

Sometimes the text object is used in a projection that makes it look
2D. This is most often the case with signatures and credits. For these
cases, having the option to only render the front face of the font
(leaving out the extrusion and back face) would decrease render times
and trace level.

: on error do something useful (skip frame etc.)

OK this one I admit is a bad habit I have from my BASIC years :)
Anyway, it could be useful if an on_error {} block could kick in when
needed. For example:

#on_error
  #declare i=0; #declare S=seed(1492); #declare A=array[100]
  #while (i<=100) #declare A[i]=rand(S); #declare i=i+1; #end
  // the above line will generate a 'subscript out or range' error
#do
  #debug "\n"
  #debug "An error occured\n"
#end

: post_interrupt_command=

This would be an INI-only option specifying what shell command to
execute if the render was interrupted by the user.

: Additional BRDF models

I recently used a rendered which supported 11 differend BRDF
(highlights) models. Now that's cool! The authors were kind enough to
share some of their sources with me:

http://www-graphics.stanford.edu/~smr/cs348c/surveypaper.html
http://www.cs.columbia.edu/CAVE/curet/
http://www.ciks.nist.gov/appmain.htm

Some of them have properties very useful for specific tasks, such as
anisotropy (for a brushed metal look).

Well, this is it, for now .If anyone cares to implement anything from
this list, the beer's on me :-)


Peter Popov
pet### [at] usanet
ICQ: 15002700

Post a reply to this message