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

In article <bCW1OIjrykoVBR6nY5iI6VMKZ3UL@4ax.com>, Peter Popov 
<pet### [at] usanet> wrote:

> : df3 output, dfc file
...
> 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.

Maybe something could be added to my object pattern...my proximity 
pattern might also benefit from this(compute the density pattern once 
using high settings for proximity, then use the density pattern instead 
of the proximity).


> 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.

Where would you get the color data from a CSG with multiple textures? 
Just add the color contribution from every object? And you would have to 
restrict yourself to the pigment, since the other features(normal, 
finish) kind of depend on having a surface.


> : strict variable types
...
> : promotion
...

I have often wished for this. I think the basic types would be:
char
int
float(maybe replace int and float with "scalar"?)
material, media, color_map, texture, etc.
object(all shapes would be of this type)
pattern(I really think patterns should be variable types too)
function(an isosurface function, it might be a good idea to let these be 
used in normal code too)

A clearer declaration syntax would be nice too:
#declare VarName = (Type) VariableStuff;
The closing semicolon would be used for all data types, instead of just 
for vectors and scalars.
Also, #declare and #local would only be used to create variables. You 
could then modify them without these keywords:
#declare MyCounter = (int)0;
MyCounter = MyCounter + 1;


> : 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.

I think list structures(and maybe tree structures) would also be good 
additions. Or at least the ability to add to and insert into an existing 
array.(a separate data structure would likely be easier to code and 
would have a cleaner syntax)


> : spotlight scale
> 
> Non-uniform scaling of spotlights would allow for elliptical
> spotlights.

And don't forget cylinderical lights.


> : 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.

This is an interesting idea, but couldn't it be done with the 
projected_through patch?


> : 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.

This might be a good idea. On the other hand, it would reinforce the bad 
habit of using bounded_by as a kind of CSG...(remember that with some 
settings POV can override this statement and use it's own bounding)


> : 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.

Actually, I am pretty sure it uses the default texture, which you can 
set with the #default keyword. And I think it would be extremely 
difficult to determine which object to choose the texture from...what if 
the point is enclosed in more than one object? The current behavior of 
using higher level textures or per-object textures if defined or the 
default texture otherwise seems to make more sense.


> : seeded randomness for area_light and aa jitter
> 
> This one is pretty straight-forward. It would make animation people's
> lives easier.

I don't think this is possible. Providing a seed would allow you to 
specify the sequence of random numbers used, but you still can't decide 
when they are used. If a point gets covered up doesn't need a random 
number computed or if something causes a pixel to need more numbers than 
it did before, everything get unsynchronized and you end up with the 
same "flying pixels" or static.


> : 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).

I will have to look at those sites...

Other features I can think of:
Simple shaders: really just an extended isosurface function capable of 
handling vectors and colors. Not necessarily as full-featured as "real" 
shaders, but potentially quite useful.

Patterned light_source's: Have the ability to apply a patterned 
color_map to a light source, with the option to use ray direction and 
depth instead of point position.(which would kind of simulate light 
coming through a colored, transparent sphere surrounding the light 
source, but with depth)
light_source {blah, blah
   PATTERN
   color_map {...}
   use_depth_for_z on/off
}

If the "use_depth_for_z"(somebody please come up with a better keyword!) 
feature is turned on, the angles of the initial emission from the light 
source will be used for the x and y axis, and the distance the ray has 
travelled for the z axis. This should make things like interference 
patterns possible.(I wonder what this would look like combined with 
scattering media and photons!)

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

>Patterned light_source's: Have the ability to apply a patterned
>color_map to a light source, with the option to use ray direction and
>depth instead of point position.(which would kind of simulate light
>coming through a colored, transparent sphere surrounding the light
>source, but with depth)
>light_source {blah, blah
>   PATTERN
>   color_map {...}
>   use_depth_for_z on/off
>}
>
>If the "use_depth_for_z"(somebody please come up with a better keyword!)
>feature is turned on, the angles of the initial emission from the light
>source will be used for the x and y axis, and the distance the ray has
>travelled for the z axis. This should make things like interference
>patterns possible.(I wonder what this would look like combined with
>scattering media and photons!)


My concept of patterned lightsources would look like this:

light_source {Pos 1}
sphere {0,1 pigment {Blah with filter in some places} scale .0001 translate
Pos}

This would make the sphere dissapear with antialiasing, and would "pattern"
the lightsource, right?

PS: Credits to Chris Colefax for this method which was passed on to me.

Post a reply to this message

>: 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.


mmmmm. Sounds interesting

>: 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.


Isn't that better done with clipped by? Or do you want to merge the two?

>: 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.


That would make my life SO much easier. Difficult to
implement though (Think of the following:
difference {
 union {
  sphere {
    <0,0.5,0>,1
    pigment {Red}
   }
   sphere {
    <0,-0.5,0>,1
    pigment {Blue}
   }
  }
  box {
   <0,-2,-2>,<2,2,2>
  }
 }

What colour should the overlapped area of the spheres be?
Red, Blue or Purple?

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


Another I would like :
 The ability to layer a texture over a complex CSG when each
part has its own texture (If this is possible without using two copies of
the object, please
let me know)

union {
  object {A texture {A}}
  object {B texture {B}}
  texture {PartiallyTransparentTexture layered}
}

The last texture should be layered over the others, instead
of just applying to objects without a texture.

Gail
*******************************************************************
* gsh### [at] monotixcoza              * ERROR: COFFEE.COM not found  *
* http://www.rucus.ru.ac.za/~gail/ * Insert cup and press any key *
*******************************************************************
* Definition of an upgrade: Take the old bugs out, put new ones in*
*******************************************************************

Post a reply to this message

In article <38b63a7e@news.povray.org>, "Gail Shaw" 
<gsh### [at] monotixcoza> wrote:

> The last texture should be layered over the others, instead
> of just applying to objects without a texture.

That is a good idea, although it would have to be used with a version 
switch. Maybe also provide for switching this off for specific objects, 
something like:
union {
    no_layer_over {
        object {MyObject1 texture {A...}}
    }
    object {MyObject2 texture {B...}
    ...

    texture {C...}
}
MyObject1 would have texture A, and only texture A. MyObject2 would have 
texture B with texture C layered over it. This would be nice if you have 
a CSG with dozens of parts and which has one with a different texture. 
no_layer_over(again, can someone please come up with a better keyword?) 
could act like a kind of union, and contain multiple objects. Perhaps it 
could contain the texture for it's objects itself...
Of course, this would need to be controlled by a #version switch, 
otherwise nearly every CSG ever done will need to be redone.

Also, remove the limitations on layering patterned textures.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

In article <38b609b4@news.povray.org>, "TonyB" 
<ben### [at] panamac-comnet> wrote:

> My concept of patterned lightsources would look like this:
> 
> light_source {Pos 1}
> sphere {0,1 pigment {Blah with filter in some places} scale .0001 
> translate
> Pos}
> 
> This would make the sphere dissapear with antialiasing, and would 
> "pattern" the lightsource, right?

Not quite...that would give the same result as my method would if it 
used a pigment(*) that was the same color along the z axis using the 
use_depth_for_z option. Or if you used a radial pattern centered over 
the light_source(or any other pattern which goes outward from a point 
but doesn't change with distance) with that option turned off.

With use_depth_for_z off, the color of the light at a point would depend 
on the color of the pigment at that point. With it on, it would depend 
on the starting angle *and the distance the light has travelled*. You 
could use a gradient z pattern and turn use_depth_for_z on, and get an 
approximation of the wave behavior of light. The angle on the x and y 
axis's(axii?) would be used for the x and y values, and the distance the 
light has travelled to the evaluation point would be used for z. This 
should be doeable, even with photon mapping.


(*)Another thing I forgot, a pigment would be useable as the color for 
this light, just the pigment keyword would be unnecessary.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

Peter Popov <pet### [at] usanet> wrote:
: unsigned int     2 bytes         0 .. 65536  larger counters, indices

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

  The integer type should be the default integer type of the system. For
most computers it's 4 bytes.
  Making 2-bytes integers would just slow down the program.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Peter Popov <pet### [at] usanet> wrote:
: : chop pieces off with bounding

: If a bounding object is smaller than what it bounds, the results are
: unpredictable.

  Nope. They are very predictable. Only a ray hitting the bounding object
can hit the bounded object.

  A bounding box is a bounding box, not a clipping box. The current
implementation is the correct one. It should be documented better to
avoid confusion, but it's correct.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Chris Huff wrote:

> Also, remove the limitations on layering patterned textures.

The biggest single question I have is what are you breaking by removing
the current restriction. I have a feeling that it is there for a good
reason but not being a coder do not know what that reason is.

-- 
Ken Tyler -  1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

Gail Shaw <gsh### [at] monotixcoza> wrote...
>
> That would make my life SO much easier. Difficult to
> implement though (Think of the following:
> difference {
>  union {
>   sphere {
>     <0,0.5,0>,1
>     pigment {Red}
>    }
>    sphere {
>     <0,-0.5,0>,1
>     pigment {Blue}
>    }
>   }
>   box {
>    <0,-2,-2>,<2,2,2>
>   }
>  }
>
> What colour should the overlapped area of the spheres be?
> Red, Blue or Purple?

None of those.  The overlapped area should be the color of the box.  The
surface in question could either belong to the box or to the whole CSG, but
it couldn't belong to either (or both) of the spheres.

If the box has not texture and you don't specify one for the CSG, then you'd
get the default texture.


>  The ability to layer a texture over a complex CSG when each
> part has its own texture (If this is possible without using two copies of
> the object, please
> let me know)
>
> union {
>   object {A texture {A}}
>   object {B texture {B}}
>   texture {PartiallyTransparentTexture layered}
> }
>
> The last texture should be layered over the others, instead
> of just applying to objects without a texture.
>

This could be a very useful feature.  I'd say that you should use a syntax
something like:

union {
  object {A texture {A}}
  object {B texture {B}}
  add_layer {PartiallyTransparentTexture layered}
}

Note that the keyword used is 'add_layer' instead of 'texture'.  I
personally don't like the way that layered textures are currently specified
(it has produced unexpected results for me on many occasions before I looked
at the source code).  Therefore, this is just a quick brainstorm suggestion
(probably not something that I will endorse in the future).

-Nathan

Post a reply to this message