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

Chris Huff wrote in 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.


For backward compatability I would think the other way round would be
better:

union {
 layered_union

  object {A texture {A}}
  object {B texture {B}}
  texture { PartiallyTransparent}
 }
 object {C texture {C}}
}

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

Nathan Kopp wrote in message <38b68a04@news.povray.org>...
>
>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.
>


I was replying to Peter's suggestion and illustrating a possible problem.

Peter Popov wrote :
>>>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.

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

Chris Huff <chr### [at] yahoocom> wrote...

> axis's(axii?)

"axes"

-Nathan

Post a reply to this message

Ken <tyl### [at] pacbellnet> wrote...
>
> 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.

A significant amount of code would have to be re-worked to remove this
limitation.  The limitation is caused by legacy code.  The original authors
never invisioned this feature, and thus it cannot easily be implemented.
Also, if this limitation were removed and the texturing system were made
more clean and consistent, we may run into backwards-compatibility issues
(the details rather difficult to describe, unfortunately).

-Nathan

Post a reply to this message

Chris Huff wrote:
> 
> In article <bCW1OIjrykoVBR6nY5iI6VMKZ3UL@4ax.com>, 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. 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)

No no no... bounding has nothing to do with CSG and should'nt be
confused with it.

> 
> 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!)

Interesting, but I think it should be done the same as sky_sphere
i.e. the colour comes from the intersection of the ray and a unit
sphere.
> 
> --
> Chris Huff
> e-mail: chr### [at] yahoocom
> Web page: http://chrishuff.dhs.org/


PoD.

Post a reply to this message

In article <38b6cbc8@news.povray.org>, "Nathan Kopp" <Nat### [at] Koppcom> 
wrote:

> A significant amount of code would have to be re-worked to remove this
> limitation.  The limitation is caused by legacy code.  The original 
> authors
> never invisioned this feature, and thus it cannot easily be implemented.
> Also, if this limitation were removed and the texturing system were made
> more clean and consistent, we may run into backwards-compatibility issues
> (the details rather difficult to describe, unfortunately).

Something for POV 4.0 maybe?

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

Post a reply to this message

In article <38b68a04@news.povray.org>, "Nathan Kopp" <Nat### [at] Koppcom> 
wrote:

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

I agree about the layered texture syntax...if someone rewrites it, it 
might also be a good idea to specify the way a texture's contribution is 
calculated: additive, multiplicative, subractive, darken, lighten, etc. 
Something like my old transparency patch(which never got finished). The 
ability to access layers by index might be useful too. Something like:
texture_layers {
   add_layer {subtractive MyTexture// Adds a texture to the list
      at layer_top// or layer_bottom, or index value
   }
   replace_layer {additive MyTextureB// replaces a texture in the list
      at layer_bottom// or layer_top, or index value
   }
   
   //removes a layer from the list
   remove_layer layer_top// or layer_bottom, or index value
}

However, most of the time only "add_layer" would be needed. The only 
uses I can think of for the other keywords would be for modifying 
existing declared objects(not that this wouldn't often be useful...). 
The same would go for the "at" keyword for specifying the position of 
the layer: the default would be layer_top, and so the order could be 
specified just by adding them in order.

And of course this could be a lot of trouble to implement in the current 
code. Another possibility for 4.0?

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

Post a reply to this message

In article <38B6E4BC.977FD8A0@merlin.net.au>, PoD <pod### [at] merlinnetau> 
wrote:

> > 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)
> 
> No no no... bounding has nothing to do with CSG and should'nt be
> confused with it.

That is what I was trying to get at-if bounding boxes chop off pieces of 
the object instead of behaving as they currently do, people will mistake 
them for a type of CSG more often. This is a bad thing. I don't want it 
to happen.


> > 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!)
> 
> Interesting, but I think it should be done the same as sky_sphere
> i.e. the colour comes from the intersection of the ray and a unit
> sphere.

But that would make it a lot less flexible...you wouldn't be able to 
simulate the wave-like characteristics of light, for example. It would 
be the same as placing a small-scaled sphere around the light source.

Hmm, you could even do a cheap imitation of laser beams without photons: 
use the object pattern with two cylinders meeting at a mirror as the 
pigment for the light, and use scattering media with isotropic 
scattering(this would be important, because although the light would 
seem to be constrained to the two cylinders, it's direction would still 
be away from the light_source). This would be messed up by shadows, but 
it is an interesting possible use.

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

Post a reply to this message

Some wishes arising from my current projects:

Dynamic arrays. In POV, arrays are the best way to acces large datasets, but the
size of the array has to be declared before any data is inserted. The thing is,
you often don't know how much data will be generated. And manually resising a
100,000 element array is inefficient, to say the least.

Better I/O support, such as read/write offset, insertion etc.

Margus

Peter Popov wrote:
> 
> 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.
>

Post a reply to this message

In article <38B711FF.1E959678@peak.edu.ee>, Margus Ramst 
<mar### [at] peakeduee> wrote:

> Some wishes arising from my current projects:
> 
> Dynamic arrays. In POV, arrays are the best way to acces large 
> datasets, but the size of the array has to be declared before any 
> data is inserted. The thing is, you often don't know how much data 
> will be generated. And manually resising a 100,000 element array is 
> inefficient, to say the least.

Or list and maybe binary tree structures. I actually started on a list 
patch, but realized it was out of my range after looking at the array 
code. Append, resize, and insert functions for an array should be fine, 
but how would multiple dimensions be handled? Maybe a dynamic_array 
which behaves like a C++ STL vector.(If you are not familiar with this, 
it is an object type, a container class which is basically a dynamic 
one-dimensional array. It includes functions for appending, inserting, 
etc)

Maybe also a kind of "pointer". With the appropriate saveguards against 
accessing memory it shouldn't, of course.

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

Post a reply to this message

Chris Huff wrote:
> 
> In article <38B6E4BC.977FD8A0@merlin.net.au>, PoD <pod### [at] merlinnetau>
> wrote:
> 
> > > 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)
> >
> > No no no... bounding has nothing to do with CSG and should'nt be
> > confused with it.
> 
> That is what I was trying to get at-if bounding boxes chop off pieces of
> the object instead of behaving as they currently do, people will mistake
> them for a type of CSG more often. This is a bad thing. I don't want it
> to happen.

Oh OK it looks like we agree on this.
> 
> > > 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!)
> >
> > Interesting, but I think it should be done the same as sky_sphere
> > i.e. the colour comes from the intersection of the ray and a unit
> > sphere.
> 
> But that would make it a lot less flexible...you wouldn't be able to
> simulate the wave-like characteristics of light, for example. It would
> be the same as placing a small-scaled sphere around the light source.
> 
> Hmm, you could even do a cheap imitation of laser beams without photons:
> use the object pattern with two cylinders meeting at a mirror as the
> pigment for the light, and use scattering media with isotropic
> scattering(this would be important, because although the light would
> seem to be constrained to the two cylinders, it's direction would still
> be away from the light_source). This would be messed up by shadows, but
> it is an interesting possible use.

I didn't mean not to include the z-depth option, just that using planar
mapping would make a lot of uses difficult.  Maybe reuse the mapping
keyword here, I could see at least spherical, planar and cylindrical
being useful.

Here's something if you had z-depth.  Use a density file as the pattern
and project 'solid' holograms into media with shadowing from intervening
objects :)

PoD.

Post a reply to this message

In article <38B7FCCF.A533B213@merlin.net.au>, PoD <pod### [at] merlinnetau> 
wrote:

> I didn't mean not to include the z-depth option, just that using planar
> mapping would make a lot of uses difficult.  Maybe reuse the mapping
> keyword here, I could see at least spherical, planar and cylindrical
> being useful.

Not planar mapping, spherical mapping. Distance would be z, and 
vertical/horizontal angle would be x and y, and the center would be the 
light_source position. It would be like wrapping the pigment around the 
sphere, except the color also varies depending on it's distance from the 
center of the sphere. You would have to tile it in some cases(many times 
the tiling wouldn't be visible), but I don't see any other way of 
mapping 3D space around a point. Maybe also cylinderical mapping.


> Here's something if you had z-depth.  Use a density file as the pattern
> and project 'solid' holograms into media with shadowing from intervening
> objects :)

That is an idea...although I guess it could also be done with scattering 
media using the density file and a plain colored light, at least as long 
as no other lights interact with it.

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

Post a reply to this message

On Thu, 24 Feb 2000 21:01:48 -0500, Chris Huff
<chr### [at] yahoocom> wrote:

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

Actually this is one of the major benefits of this idea. The proximity
is dreadfully slow in media (and probably isosurfaces). If it could be
calculated only once, render times would be greatly cut down.

Significant reduction of render times can be achieved if complex media
statements are replaced with precomputed density patterns. My current
project involves the usage of 200 scattering media statements in a
single blob container. It takes more than nine hours to render at
640x480. If it were a single df3 media, render times could be
dramatically decreased (by an order of ten to a hundred, depending on
the scene)

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

The problem with overlapping interiors may or may not be possible to
be solved by proper CSG. Maybe if the objects are tested in a specific
order (for example the order they appear in the CSG) and the first
match is returned, the problem would go away. And yes, only pigments
would be used, but that should be enough to model things such as

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

No, because the falloff (for spotlights) would still be circular and
not polygonal.

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

I admit it is probably a bad idea anyway, especially because it would
duplicate the functionality of the CSG texture patch if it gets
implemented. The idea for both modifications came to me when I had a
complex CSG of objects with their own textures and I wanted to make a
cross-section of it. Although I succeeded to do it with bounding,
rotating the object or camera lead to unpredictable results. So I am
proposing both patches because I can't tell right now which one would
be easier/simlper/safer to possibly implement.

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

I guess so, but it still poses the same problem.

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

If more then one objects enclose the point, use the texture of that
one which appears first (or last) in the CSG.

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

I didn't mean the user should specify the seed, rather that the seed
should be constant for each pixel (for example X+Y). This would
eliminate the "flying pixels" static.

>I will have to look at those sites...

My heart fills with hope... :)

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

Ditto. Combine this with custom BRDFs and you have infinite
possibilities.

>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!)

I've raised the question of simulating wave properties (wavelength,
phase and polarization) a couple of times myself but it was
overlooked. Your idea is certainly more versatile and I see good uses
for it already.


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

Post a reply to this message

On Sat, 26 Feb 2000 06:53:24 +1030, PoD <pod### [at] merlinnetau> wrote:

>No no no... bounding has nothing to do with CSG and should'nt be
>confused with it.

I know, I know, but there are certain limitations in the current CSG
model that could be avoided this way.


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

Post a reply to this message

On Fri, 25 Feb 2000 10:16:09 +0200, "Gail Shaw" <gsh### [at] monotixcoza>
wrote:

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

Neither. I want to see the texture of an arbitraty object where it
intersects its (manual!) bounding object. Chris and PoD (and probably
others) already pointed out the major problem, that some users might
be lead into believing that bounding is a type of CSG, and this is a
Real Bad Thing(tm). I am giving up this idea in favour of the next one
(which duplicates this functionality anyway).

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

Replace it with this:
difference {
 union {
  intersection { sphere { 0.5*y, 1 } plane { -y, 0 } pigment { Red } }
  intersection { sphere { -0.5*y, 1 } plane { y, 0 } pigment { Red } }
 }
 box { <0,-2,-2>, <2,2,2> }
}

and you'll see what I mean by "proper CSG" :)

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

This would certainly be useful. It can be done without a separate copy
of the object if each piece of the CSG has the desired texture layered
over its own.


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

Post a reply to this message

On 25 Feb 2000 08:13:05 -0500, Nieminen Juha
<war### [at] sarakerttunencstutfi> wrote:

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

Suppose the bounding box is smaller than the object itself. If and
only if a ray hits the box, it will look for the first intersection
with the object itself _along_the_ray_ and that intersection could
easily be outside the bounding box! So if you have a sphere bounded by
a smalled box, the result would look as if you've rendered the sphere
and then applied to the resulting image an alpha channel based on the
box. This, in my dictionary, is not correct.

Of course specifying a bounding box smaller than the bounded object is
incorrect in the first place :) but there are a few trick (besides
vampires and anti-vampires) that can be done with it.


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

Post a reply to this message

Peter Popov wrote:

> 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.
> : 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 just took a quick look at the site. The velvet rendering is incredible!

Post a reply to this message

In article <kfK3OIjBjxu=lEMtvnZip=3GMUqx@4ax.com>, Peter Popov 
<pet### [at] usanet> wrote:

> Significant reduction of render times can be achieved if complex media
> statements are replaced with precomputed density patterns. My current
> project involves the usage of 200 scattering media statements in a
> single blob container. It takes more than nine hours to render at
> 640x480. If it were a single df3 media, render times could be
> dramatically decreased (by an order of ten to a hundred, depending on
> the scene)

Have you tried the blob pattern/pigments? Those may help...my original 
idea was that they would be good density patterns for media.


> No, because the falloff (for spotlights) would still be circular and
> not polygonal.

Hmm, shouldn't an area light work with projected_through to get that?


> >> : 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. 
> 
> I guess so, but it still poses the same problem.

> If more then one objects enclose the point, use the texture of that
> one which appears first (or last) in the CSG.




> I didn't mean the user should specify the seed, rather that the seed
> should be constant for each pixel (for example X+Y). This would
> eliminate the "flying pixels" static.

Hmm, that might work...


> I've raised the question of simulating wave properties (wavelength,
> phase and polarization) a couple of times myself but it was
> overlooked. Your idea is certainly more versatile and I see good uses
> for it already.

I actually have a very early version done already. It doesn't work with 
photons(I have to figure out how to get the evaluation point in the 
right part of the code before that will work), and there might be some 
other oddities I haven't found yet, but the straight mapping works. I 
haven't added spherical and cylinderical mappings yet, so it doesn't 
have depth dependant effects yet.

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

Post a reply to this message

There are three similar things: Bounding, clipping and the intersection CSG.
They functions are, however, very different and should not be confused.
  What you are talking about, actually, is this:

  intersection
  { object { MyObject }
    object { BoundingObject }
    bounded_by { BoundingObject }
  }

  Since it can be done, and it's very intuitive, it should not be changed.
It should, however, be documented better.
  For some reason I have never had any confusion about these three things.

-- 
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...
> The problem with overlapping interiors may or may not be possible to
> be solved by proper CSG. Maybe if the objects are tested in a specific
> order (for example the order they appear in the CSG) and the first
> match is returned, the problem would go away. And yes, only pigments
> would be used, but that should be enough to model things such as

Another possibility would be to use an average of textures, in the same way
as multi-textured blobs or the new vertex-textured meshes.  It would
probably just be a straight average (as opposed to a weighted average) to
avoid any proximity testing (which can be really slow, as we've seen).

Unfortunately, this is difficult to implement currently because of the way
that CSG intersections are handled.  It may not be that bad, though... I'll
have to look at it more closely and let you know.

> >> : polygonal spotlight
> >
> >This is an interesting idea, but couldn't it be done with the
> >projected_through patch?
>
> No, because the falloff (for spotlights) would still be circular and
> not polygonal.

Well, that changes things (and makes them much more difficult to implement).

>
> >> : chop pieces off with bounding
>
> I admit it is probably a bad idea anyway, especially because it would
> duplicate the functionality of the CSG texture patch if it gets
> implemented. [clip] So I am
> proposing both patches because I can't tell right now which one would
> be easier/simlper/safer to possibly implement.

Understood.

> Ditto. Combine this with custom BRDFs and you have infinite
> possibilities.

Custom BRDFs sounds really fun (though they can be slow).

> I've raised the question of simulating wave properties (wavelength,
> phase and polarization) a couple of times myself but it was
> overlooked. Your idea is certainly more versatile and I see good uses
> for it already.

Actually, it wasn't overlooked, just avoided due to perceived complexity.

-Nathan

(I am speaking for myself, not the POV-Team.)

Post a reply to this message

Peter Popov <pet### [at] usanet> wrote...
> : strict variable types

I think that the non-programmers might balk at this.  I like the way that
renderman handles this by linking in to existing languages and thus only
providing core functionality instead of syntax.  However, for good or bad,
POV is not currently heading in that direction.

A minimal amount of stricter variables might be good, but I personally lean
more towards looser variable types.  For efficiency reasons (as you pointed
out), it might be a good idea to allow the user to specify a few
smaller/faster variable types.  But careful attention would have to be paid
to making it easy to use.  Therefore, many paradigms from other programming
languages (C/C++ especially) should not be used because the are not easy to
learn and often difficult to use.  Sure, they might be easy for most of us
in _this_ group, but there will be far more non-programmers who will not
want to have to worry about what type of variable they need to use to get
the precision they want.

Therefore, I would probably just add integer types (maybe char, but most
likely not).  And I'm pretty sure I'd totally avoid any unsigned types.

> : promotion

Promotion is currently automatically done when needed.  I like that approach
better.  Sure, automatic type casting can lead to unexpected results if the
coder doesn't pay attention to what they're doing, but if there the number
of variable types is kept to a minimum, and a logical promotion sequence is
used, then this can greatly ease the task of the coder.

> : hash variables
> For example,
> Posters[155] doesn't tell much while Posters[Peter_Popov] does, and
> they mean the same to the parser.

Current POV code:

#declare Peter_Popov = 155;
#declare ABC=Posters[Peter_Popov];

Maybe what you're looking for is this:
#declare ABC=Posters["Peter_Povpov"];

> : media emission/absorption color map

I agree.

> : patterned turbulence, turbulence_map

I agree.

> : spotlight scale

I'm not quite sure how to code this, but it sounds rather useful.

> : polygonal spotlight

My first thought is to use projected_through.  Do that with an area light
and you get realistic falloff, although I realize that doing such would not
be as fast as what you are proposing.

> : better alpha channel support

I agree.

> : displacement mapping for patterns

Sounds interesting.

> : chop pieces off with bounding

Use CSG.

> : leave original textures when CSGing

Probably won't work as well as you'd expect.  But I don't want to dismiss it
without looking closely.  It is potentially a very useful idea and may not
be as difficult to implement as I am imagining.  I would definately say that
it should be a special option for backwards compatibility reasons.

> : seeded randomness for area_light and aa jitter

As mentioned by Chris, this may not be possible.

> : zero text object thickness

Sounds good for rendering speed reasons.  On the other hand, maybe a TTF
pattern would be better.  This way you could apply the TTF object to another
infinitely thin object (such as a disc) and use filter/transmit to get the
clear part.

> : on error do something useful (skip frame etc.)
>
> OK this one I admit is a bad habit I have from my BASIC years :)

Actually, your example looks quite a bit like an exception-handling block,
and I see a lot of potential usefullness in it.

> : Additional BRDF models

I totally agree.  Also, not simply _more_ BRDF models, but _better_ BRDF
models.

-Nathan

(I speak for myself and not for the POV-Team.)

Post a reply to this message

I have one more suggestion (or the modification of a feature):

  When you write something to, for example, the #warning stream, the given
string is printed there ok.
  However, if you try to print something to the #error stream, nothing is
printed, but the parsing stops and povray shows some lines where the "error"
occurred.
  This is quite useless if you have something like:

#error concat("Expected value between ", str(minval,0,0), " and ",
              str(maxval,0,0), ", but ", str(value,0,0), " was specified.")

  Showing that helps no-one. However, printing that message and stopping
(without showing any source code) would be more useful.

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

In article <38b81aa4@news.povray.org>, "Nathan Kopp" <Nat### [at] Koppcom> 
wrote:

> Peter Popov <pet### [at] usanet> wrote...
> > : strict variable types
> 
> I think that the non-programmers might balk at this.  I like the way 
> that renderman handles this by linking in to existing languages and 
> thus only providing core functionality instead of syntax.  However, 
> for good or bad, POV is not currently heading in that direction.

Maybe we should make a separate language just for us programmers with a 
converter to .pov files. :-)
Bad idea, I know. Unless there was an editor which automatically 
"compiled" to POV and rendered the scene, it would just be too clumsy a 
system to use. Maybe give POV two different parsers? Or make that 
possible in a later version while rewriting the source?


> A minimal amount of stricter variables might be good, but I 
> personally lean more towards looser variable types.  For efficiency 
> reasons (as you pointed out), it might be a good idea to allow the 
> user to specify a few smaller/faster variable types.  But careful 
> attention would have to be paid to making it easy to use.  Therefore, 
> many paradigms from other programming languages (C/C++ especially) 
> should not be used because the are not easy to learn and often 
> difficult to use.  Sure, they might be easy for most of us in _this_ 
> group, but there will be far more non-programmers who will not want 
> to have to worry about what type of variable they need to use to get 
> the precision they want.

This is true...maybe types aren't such a good idea, even though they 
would be useful in some of the more complex include files and scenes.
However, I would like to see #declare and #local only be used to 
*create* variables, with either another keyword(#let?) or no keyword at 
all required to modify a variable, something like:
#declare K=0;// creates a variable K
#let K=K+1;// adds 1 to the variable K
K=K+1;// adds 1 to the variable K
This would make a lot of the includes easier to read and maintain, and 
would make debugging easier, since it is clearer where a variable is 
first created.


> > : displacement mapping for patterns
> 
> Sounds interesting.

I think the pattern-vector_map approach would be best for this...any 
other ideas?


> > : zero text object thickness
> 
> Sounds good for rendering speed reasons.
> On the other hand, maybe a TTF pattern would be better.  This way you 
> could apply the TTF object to another infinitely thin object (such as 
> a disc) and use filter/transmit to get the clear part.

Something like this? :-)
pigment {
    object {
        text {ttf "crystal.ttf", "my testing text", 1, 0
            translate -z*0.001//to avoid co-incident surface problems
        },
        color White filter 1, color Blue
    }
}
My object pattern was originally a text pattern, it was just more 
versatile to let it use any object.


> > : Additional BRDF models
> 
> I totally agree.  Also, not simply _more_ BRDF models, but _better_ BRDF
> models.

I agree too, now that I have an idea of what one is...but what would a 
good syntax be? And how well would they coexist?

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

Post a reply to this message

Chris Huff <chr### [at] yahoocom> wrote...
> This is true...maybe types aren't such a good idea, even though they
> would be useful in some of the more complex include files and scenes.
> However, I would like to see #declare and #local only be used to
> *create* variables, with either another keyword(#let?) or no keyword at
> all required to modify a variable, something like:
> #declare K=0;// creates a variable K
> #let K=K+1;// adds 1 to the variable K
> K=K+1;// adds 1 to the variable K
> This would make a lot of the includes easier to read and maintain, and
> would make debugging easier, since it is clearer where a variable is
> first created.

Personally, I disagree.  For non-compiled, scripting languages, I like
features such as automatic variable creation and run-time scoping.
I don't like #declare and #local.  I like $ and % instead.  ;-)

$k=0;
$k=k+1;

Run-time scoping, loose variable types, and automatic creation of variables
are 'features' of scripting languages.  This is different from compiled
procedural languages, but 'different' does not necessarily mean 'wrong'.

Finally, because of the way POV's scene-description language is defined,
your example of the assignment with neither #declare or #let would probably
cause ambiguity in the parser, and fixing that would likely lead to
backwards compatibility issues.

See p.t.s-f for an example of run-time scoping.

-Nathan

Post a reply to this message

>I think that the non-programmers might balk at this.

I wouldn't mind if you could make it so that both types of users could work
happily: that is, for POV to support both syntaxes, this way

#declare Whatever = something;

would be just as valid as

#declare Whatever = (int) something;

Of course, this would mean that the programmers would have to be nice enough
to provide dual versions of their files for those who couldn't understand C.
Although, maybe non-programmers wouldn't mind in the case that you had an
include that does something that greatly benefits from these specific
variable types and they had to reason to read the include, just #include it
and enjoy the benefits. Right?

Post a reply to this message

On 26 Feb 2000 13:14:43 -0500, Nieminen Juha
<war### [at] sarakerttunencstutfi> wrote:

>  There are three similar things: Bounding, clipping and the intersection CSG.
>They functions are, however, very different and should not be confused.
>  What you are talking about, actually, is this:
>
>  intersection
>  { object { MyObject }
>    object { BoundingObject }
>    bounded_by { BoundingObject }
>  }
>
>  Since it can be done, and it's very intuitive, it should not be changed.
>It should, however, be documented better.
>  For some reason I have never had any confusion about these three things.

I have not either. Perhaps you have missed my main point, and it is
textures. Imagine you have this:

intersection
{ union
  { sphere { -x, 1 pigment { Red } }
    sphere { x, 1 pigment { Blue } }
  }
  box { <-3,0,-2>, <3,2,2> }
}

Now, there is no simple way to make the surfaces of the spheres that
show up after being chopped off preserve their texture. They get the
texture of the box, which in this example is default or black. If
this:

union
{ sphere { -x, 1 pigment { Red } }
  sphere { x, 1 pigment { Blue } }
  bounded_by { box { <-3,0,-2>, <3,2,2> } }
}

worked in the desired way it would make certain tasks easier. Either
that, or the way CSG works could be modified for the purpose.


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

Post a reply to this message

On Sat, 26 Feb 2000 13:22:22 -0500, "Nathan Kopp" <Nat### [at] Koppcom>
wrote:

>Therefore, I would probably just add integer types (maybe char, but most
>likely not).  And I'm pretty sure I'd totally avoid any unsigned types.

These should suffice, really. And at first I didn't realize the
problems a person with no programming background might run into when
working with unsigned types. You're right, leave'em out.

>> : promotion
>
>Promotion is currently automatically done when needed.  I like that approach
>better.  Sure, automatic type casting can lead to unexpected results if the
>coder doesn't pay attention to what they're doing, but if there the number
>of variable types is kept to a minimum, and a logical promotion sequence is
>used, then this can greatly ease the task of the coder.

I will have to trust you on this one because you're the programmer,
not me :)

>Maybe what you're looking for is this:
>#declare ABC=Posters["Peter_Povpov"];

Yes, of course you're right, a string used as an index is what I had
in mind.

>> : polygonal spotlight
>
>My first thought is to use projected_through.  Do that with an area light
>and you get realistic falloff, although I realize that doing such would not
>be as fast as what you are proposing.

I think Stephan Ahonen was working on such an extension for Blender
(I'll have to check my ICQ message archive). I'll see if I can get him
(or whoever it was who worked on that project) share some source.

>Use CSG.

I'm just giving this idea up because it is not a really good one.

>> : leave original textures when CSGing
>
>Probably won't work as well as you'd expect.  But I don't want to dismiss it
>without looking closely.  It is potentially a very useful idea and may not
>be as difficult to implement as I am imagining.  I would definately say that
>it should be a special option for backwards compatibility reasons.

My heart is filled with hope :)

>> : seeded randomness for area_light and aa jitter
>
>As mentioned by Chris, this may not be possible.

Use the pixel coordinates as a seed and there you go!

>> : zero text object thickness
>
>Sounds good for rendering speed reasons.  On the other hand, maybe a TTF
>pattern would be better.  This way you could apply the TTF object to another
>infinitely thin object (such as a disc) and use filter/transmit to get the
>clear part.

Also, support for '\n' and '\t' in text objects (and for '\t' in
strings) would be useful. Stuff like justification would probably be
overkill (and can be done with a macro anyway).

>> : on error do something useful (skip frame etc.)
>>
>> OK this one I admit is a bad habit I have from my BASIC years :)
>
>Actually, your example looks quite a bit like an exception-handling block,
>and I see a lot of potential usefullness in it.

Really? But that would involve return codes for most operations etc.
Also, what would happen if this block in included, or even worse,
overlaps, a #while..#end, #if..#end or even a #macro..#end block?

>> : Additional BRDF models
>
>I totally agree.  Also, not simply _more_ BRDF models, but _better_ BRDF
>models.

Ditto to that.


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

Post a reply to this message

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

>>Therefore, I would probably just add integer types (maybe char, but most
>>likely not).  And I'm pretty sure I'd totally avoid any unsigned types.
>
> These should suffice, really. And at first I didn't realize the
> problems a person with no programming background might run into when
> working with unsigned types. You're right, leave'em out.

When using only integer types, I think the whole thing can be hidden from
the user and POV-Ray automatically determines the type (floating-point or
integer). This allows for hiding the type from the user, and in loop, etc
even new users would get the benefit without ever having to deal with
variable types.

For a #declare (of a so far undefined variable) just check if the value is
an integer and then store it as such.  I.e. "#declare MyFoo = 1" is an
integer, but neither would be "#declare MyFoo = 1.0" or "#declare MyFoo =
1.8542".  Now, whenever a floating-point result is to be assigned to this
integer, promote "MyFoo" to floating-point (for backward compatibility!).

User control can still be available, i.e. introducing two functions to
eliminate the common operations that should create floating-point results:
For division offer a Pascal style "div" function (or even operator), and to
still allow mixing integer and floating-point math without forcing promotion
to floating-point for the result, an "int" function which can be placed
around any section of a function, for example "#declare MyFoo = 1; #declare
MyFoo = 8084 div 7 + MyFoo - (int(sin(45) * 10) * MyFoo;" would still give
in an integer result.

During evaluation this should still be possible with (nearly?) no runtime
penalty.


     Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany

Post a reply to this message

Margus Ramst wrote in message <38B711FF.1E959678@peak.edu.ee>...
>Some wishes arising from my current projects:
>
>Dynamic arrays. In POV, arrays are the best way to acces large datasets,
but the
>size of the array has to be declared before any data is inserted. The thing
is,
>you often don't know how much data will be generated. And manually resising
a
>100,000 element array is inefficient, to say the least.


I've been working on "malloc", "realloc", and "free" macros.  However, the
current version of "realloc" is very slow, since it works by creating a new
array and copying the old one into it.

Mark

Post a reply to this message

Peter Popov <pet### [at] usanet> wrote:
: I have not either. Perhaps you have missed my main point, and it is
: textures. Imagine you have this:

: intersection
: { union
:   { sphere { -x, 1 pigment { Red } }
:     sphere { x, 1 pigment { Blue } }
:   }
:   box { <-3,0,-2>, <3,2,2> }
: }

  But that's not possible. Suppose that the radiuses of the spheres are
a bit larger (so that the spheres overlap). What's the color of the
overlapping part?
  On the other hand, even in your example: How can povray know which one
is the right sphere to get the color from? It only has knowledge of the
intersection of the ray with the box. It would have to somehow decide which
sphere is the right one. I don't know how povray works in this matter, but
it might be difficult to see which sphere is the right one. It's more difficult
if the spheres overlap or one sphere is completely inside the other.
  And besides, bounding is not intended for that kind of functionality.
Boundind is intended only for speeding up the rendering.

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

In article <38b877a0@news.povray.org>, "Thorsten Froehlich" 
<tho### [at] trfde> wrote:

> User control can still be available, i.e. introducing two functions 
> to eliminate the common operations that should create floating-point 
> results: For division offer a Pascal style "div" function (or even 
> operator), and to still allow mixing integer and floating-point math 
> without forcing promotion to floating-point for the result, an "int" 
> function which can be placed around any section of a function, for 
> example "#declare MyFoo = 1; #declare MyFoo = 8084 div 7 + MyFoo - 
> (int(sin(45) * 10) * MyFoo;" would still give in an integer result.

Those functions already exist in POV. :-)

Section 4.1.3.6  Float Functions
...
div(A,B) Integer division. The integer part of (A/B) .
int(A) Integer part of A . Returns the truncated integer part of A . 
Rounds towards zero.


Now all that has to be done is add code for deciding whether to use 
integer or floating point...btw, I think the precision should be 
specified instead of being left to the implementation of "int", it would 
make the language more consistant across platforms and compilers. Or 
maybe just have it decide depending on the size of the number-but I 
think the overhead of that(some conditionals, comparisons, and type 
conversions?) would outweigh any possible benefits.

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

Post a reply to this message

On Fri, 25 Feb 2000 19:30:39 -0500, Chris Huff wrote:
Maybe a dynamic_array 
>which behaves like a C++ STL vector.(If you are not familiar with this, 
>it is an object type, a container class which is basically a dynamic 
>one-dimensional array. It includes functions for appending, inserting, 
>etc)

I want an array that acts like a C++ STL map, too.

-- 
These are my opinions.  I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html

Post a reply to this message

Ron Parker <ron### [at] povrayorg> wrote:
: I want an array that acts like a C++ STL map, too.

  I think it's technically called "associative array".

  And yes, povray versions of the STL vectors and maps would be very handy.
  With maps there may be need for iterators.

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

Nieminen Juha <war### [at] sarakerttunencstutfi> writes:

> Ron Parker <ron### [at] povrayorg> wrote:
> : I want an array that acts like a C++ STL map, too.
> 
>   I think it's technically called "associative array".
> 
>   And yes, povray versions of the STL vectors and maps would be very handy.
>   With maps there may be need for iterators.

It appears to me, that the time for the complete rewrite in C++ 
(i.e. POV-Ray 4.0) has come. Does somebody know, whether the 
POV-Team has already started? (I'm looking forward to discuss
design and implementation issues.)

Thomas

-- 
http://thomas.willhalm.de/ (includes pgp key)

Post a reply to this message

On 28 Feb 2000 03:02:18 -0500, Nieminen Juha wrote:
>Ron Parker <ron### [at] povrayorg> wrote:
>: I want an array that acts like a C++ STL map, too.
>
>  I think it's technically called "associative array".

Actually, I knew that, since I actually use them in Perl rather than
in C++.  I was just trying for the parallelism with the original comment. :)

Perl doesn't have what you'd call "iterators" per se.  To iterate over an
associative array in Perl, you do:

  for $index ( keys( %assoc_array ) ) {
    do_stuff_with( $assoc_array{$index} )
  }

-- 
These are my opinions.  I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html

Post a reply to this message

In article <qqmd7phhh09.fsf_-_@schlatt.fmi.uni-konstanz.de> , Thomas 
Willhalm <tho### [at] willhalmde>  wrote:

> It appears to me, that the time for the complete rewrite in C++
> (i.e. POV-Ray 4.0) has come. Does somebody know, whether the
> POV-Team has already started? (I'm looking forward to discuss
> design and implementation issues.)

povray.announce.frequently-asked-questions:  "POV-Ray plans for v3.1 and
beyond..."


        Thorsten

Post a reply to this message

Mark Wagner wrote:
> 
> I've been working on "malloc", "realloc", and "free" macros.  However, the
> current version of "realloc" is very slow, since it works by creating a new
> array and copying the old one into it.
> 

Yes, I've done that too, out of necessity.
It's slow, plus you want to resize it as seldom as possible so you must waste
memory on unnecessarily large arrays.

Margus

Post a reply to this message

Ron Parker <ron### [at] povrayorg> wrote:
: Perl doesn't have what you'd call "iterators" per se.  To iterate over an
: associative array in Perl, you do:

:   for $index ( keys( %assoc_array ) ) {
:     do_stuff_with( $assoc_array{$index} )
:   }

  I think this is slower than using iterators.
  Referencing to an object with an iterator is a constant-time operation
and incrementing the iterator is an amortized constant-time operation.
Thus, going through the whole array is an O(n)-time operation.
  Indexing one element with a key is an O(log n)-time operation (at least
with the STL map), so going through all elements by indexing each one of
them would be a O(n*log n)-time operation.

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

On 29 Feb 2000 07:38:29 -0500, Nieminen Juha wrote:
>Ron Parker <ron### [at] povrayorg> wrote:
>: Perl doesn't have what you'd call "iterators" per se.  To iterate over an
>: associative array in Perl, you do:
>
>:   for $index ( keys( %assoc_array ) ) {
>:     do_stuff_with( $assoc_array{$index} )
>:   }
>
>  I think this is slower than using iterators.

Yes, it is.  Unfortunately, it's the only way in Perl.  TMTOWTDI, indeed.

-- 
These are my opinions.  I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html

Post a reply to this message

On 29 Feb 2000 07:38:29 -0500, Nieminen Juha wrote:
>  Referencing to an object with an iterator is a constant-time operation
>and incrementing the iterator is an amortized constant-time operation.

Actually, I have an associative array (of sorts) that I've written here
that has an O(1) increment, not amortized.  It's a threaded 2-3 tree.  
Indexing is still, of course, O(log n), as are insertion and deletion.

-- 
These are my opinions.  I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html

Post a reply to this message