This is a really old subject, discussed a thousand times already, but
anyways, I thought about writing some of the ideas that have occurred to
me about what new features in the POV-Ray SDL would be great.
  Some of the ideas are old, but I thought that I would make a complete
list of what I think.
  I'm posting this to this group in case some patch maker could get some
inspiration for a new feature (I could try to implement these myself, but
I really don't have the time now...).
  These are features which should not be too difficult to implement.



  * Assigment shortcut operators.

  That is, +=, -=, *= and /=.
  The advantage is clear with statements like:

#declare Array[Index1*a*b+1][Index2] += 2;


  * #do - #until

  The advantage of this is that the loop condition is checked after the
loop body has been parsed and not before. This is useful for example in
sitations like this:

#do
  #declare Point = <rand(S),rand(S),rand(S)>*2-1;
#until(vlength(Point) <= 1)


  * Array operators for the string type.

  A string could be accessed as an array. For example:

#declare I = MyString[a];

  would be completely equivalent to:

#declare I = asc(substr(MyString, a, 1));

  However, it would not only be a shortcut since this would work as well:

#declare MyString[a] = 65;


  * Float literals written as ascii chars (as in C).

  This way the above could be written as:

#declare MyString[a] = 'A';


  * Binary file reading and writing.

  A read-command which reads (the specified amount of) raw binary data into
a string identifier. In the same way it should be possible to directly
write a string as raw data to a file (IIRC currently this is not possible
because of a bug which causes the value 0 to not be written).
  Also a seeking command would be good.


  * Handling bitmaps with a 2-dimensional color array.

  A function should be added which reads the given image file into a given
identifier, which is created as a 2-dimensional array of colors (exactly
as if created by #declare Image = array[Width][Height];).
  Also every item in POV-Ray which accepts an image should also accept
such array of colors.
  (Note: Functions for reading the image dimensions are not necessary
because such function already exists: dimension_size().)


  * Reading members of the global_settings and camera data with the
dot operator.

  For example, you could do this:

#if(global_settings.max_trace_level < 15)
  global_settings { max_trace_level 15 }
#end

  Sub-blocks inside the global_settings block could be accessed in the
same way, eg:

global_settings.radiosity.error_bound


  * Some way of making dynamic data containers.

  This is a whole lot more complicated issue.
  One way of allowing this is to add support for user-defined abstract
types, for example some type of 'struct' construct in such way that you
can make instantiations of this type. This also requires having a reference
type identifier, which can point to such instantiation.
  This way it would be possible to make, for example, a linked list.
  Members of such struct would be accessed with the dot operator.

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

In article <3e889ec9@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   * Assigment shortcut operators.
> 
>   That is, +=, -=, *= and /=.
>   The advantage is clear with statements like:
> 
> #declare Array[Index1*a*b+1][Index2] += 2;

Similarly, I'd like a #set directive, which modifies existing variables 
but can not make new ones. I made a patch for this, which is included in 
MegaPOV IIRC...it reduces typing, makes code clearer, and catches some 
errors sooner.

This loops infinitely:

#declare Loops = 10;
#while(Loops > 0)
    #declare loops = Loops - 1;
#end

And this produces an error:

#declare Loops = 10;
#while(Loops > 0)
    #set loops = Loops - 1;
#end

What I'd really like is for modification to be done without any keyword, 
as it is in most other languages...for example, the Sapphire equivalent:

def j: 10;
while(j > 0)
    j -= 1;


>   * #do - #until

Why do...until() instead of do...while()? Similar constructs, but 
do...while() seems more common.
Anyway, might as well add for loops of some sort while you are at it.


>   * Array operators for the string type.

And splines. Unify splines with the ones used by shapes like lathe and 
prism too.


>   * Float literals written as ascii chars (as in C).
> 
>   This way the above could be written as:
> 
> #declare MyString[a] = 'A';

Less useful, but no real argument against it.


>   * Binary file reading and writing.
> 
>   A read-command which reads (the specified amount of) raw binary data into
> a string identifier. In the same way it should be possible to directly
> write a string as raw data to a file (IIRC currently this is not possible
> because of a bug which causes the value 0 to not be written).
>   Also a seeking command would be good.

Agreed. I'm not really happy with POV's file handling. A more complete 
implementation would allow for importation of various model formats to 
be done from a POV script...DXF import could be done as a standard 
include file. It would go a long way toward reducing the need for 
plugins.


>   * Handling bitmaps with a 2-dimensional color array.
> 
>   A function should be added which reads the given image file into a given
> identifier, which is created as a 2-dimensional array of colors (exactly
> as if created by #declare Image = array[Width][Height];).
>   Also every item in POV-Ray which accepts an image should also accept
> such array of colors.
>   (Note: Functions for reading the image dimensions are not necessary
> because such function already exists: dimension_size().)

Hmm...not very memory efficient, and doesn't hook into POV's existing 
internal image handling. A separate data type might be better.


>   * Reading members of the global_settings and camera data with the
> dot operator.
>   * Some way of making dynamic data containers.

These could both be handled with the same mechanism...things like 
global_settings would be an object with things like max_trace_level as 
members.

I've posted messages about this before, but a prototype based object 
system would fit the POV language with few changes. "object" would 
become a basic, empty object (in the object oriented programming sense), 
and all the shapes would descend from it. Prototype OOP fits how complex 
shapes are already constructed, and is simpler than class based systems. 
As for references...perhaps a link directive of some sort.
Wedging all this into the POV syntax is kind of ugly though. It would be 
cleaner to just start over from scratch. This would allow a lot of crud 
to be stripped out of the language, and let interpretation be moved over 
to a virtual machine, for a great increase in speed for complex 
computations like tree generators or particle simulations. I propose a 
simple to use language for the main scene, and a more limited, very 
tightly optimized version for things like isosurfaces and shaders.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

On Mon, 31 Mar 2003 19:44:23 -0500, Christopher James Huff
<cja### [at] earthlinknet> wrote:

> >   * Array operators for the string type.
>
> And splines.

http://megapov.inetart.net/manual/expressions.html#spline_like_array

ABX

Post a reply to this message

On 31 Mar 2003 15:02:17 -0500, Warp <war### [at] tagpovrayorg> wrote:
>  * Assigment shortcut operators.
>  * #do - #until
>  * Array operators for the string type.
>  * Float literals written as ascii chars (as in C).
>  * Binary file reading and writing.
>  * Handling bitmaps with a 2-dimensional color array.
>  * Reading members of the global_settings and camera data with the dot operator.
>  * Some way of making dynamic data containers.

Interesting and some alredy in "to do". But POV is not only for sigs ;)

ABX

Post a reply to this message

Christopher James Huff <cja### [at] earthlinknet> wrote:
>>   * #do - #until

> Why do...until() instead of do...while()? Similar constructs, but 
> do...while() seems more common.

  Because #until is unambiguous to the parser.
  When the POV-Ray parser sees the #do and a bit forward it sees a #while,
it has no way of knowing whether the #while is ending the #do or whether
it's starting a #while-loop.
  Using #until completely disambiguates this.

>>   * Handling bitmaps with a 2-dimensional color array.

> Hmm...not very memory efficient, and doesn't hook into POV's existing 
> internal image handling. A separate data type might be better.

  You are right. There could be a new "bitmap" type which is stored in
memory more efficiently than an 2-dimensional array of colors, but which
looks from the point of view of the SDL like such array. (The only difference
would be that if you want to create an identifier of type "bitmap" by other
means than using the image reasing function, there must be a special syntax
for that.)

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Warp wrote:
> 
> > Why do...until() instead of do...while()? Similar constructs, but
> > do...while() seems more common.
> 
>   Because #until is unambiguous to the parser.
>   When the POV-Ray parser sees the #do and a bit forward it sees a #while,
> it has no way of knowing whether the #while is ending the #do or whether
> it's starting a #while-loop.
>   Using #until completely disambiguates this.
> 

I'd use the pascal version:

#repeat

#until ()

this probably would avoid confusion when people simply assume it would
work like in C when they see a #do.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 28 Feb. 2003 _____./\/^>_*_<^\/\.______

Post a reply to this message

In article <3e896d52@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   Because #until is unambiguous to the parser.
>   When the POV-Ray parser sees the #do and a bit forward it sees a #while,
> it has no way of knowing whether the #while is ending the #do or whether
> it's starting a #while-loop.
>   Using #until completely disambiguates this.

Of course...without block delimiters, this is necessary.


> >>   * Handling bitmaps with a 2-dimensional color array.
> 
> > Hmm...not very memory efficient, and doesn't hook into POV's existing 
> > internal image handling. A separate data type might be better.
> 
>   You are right. There could be a new "bitmap" type which is stored in
> memory more efficiently than an 2-dimensional array of colors, but which
> looks from the point of view of the SDL like such array. (The only difference
> would be that if you want to create an identifier of type "bitmap" by other
> means than using the image reasing function, there must be a special syntax
> for that.)

Something like this?
new_image(X_SIZE, Y_SIZE, INIT_FUNCTION)
open_image(X_SIZE, Y_SIZE, TYPE, FILE_NAME)

or this:
image {X_SIZE, Y_SIZE, INIT_FUNCTION | TYPE FILE_NAME}

Some other ideas:
Declarable warps, and make "warp {}" behave more like "transform {}", 
able to hold multiple warps. There are some incompletely implemented 
features in warps as well.

Declarable patterns. We really have this already, it is just necessary 
to tweak the function pattern syntax.

Universal "blend", replacing all the *_map keywords. Maybe combine with 
splines.

Integrate textures, patterns, splines, warps, color_maps, etc with 
functions. In the process of happening now.

Separate transparency:
texture {
    pigment {...}
    
    transparency FILTER_AMT
    
    transparency FILTER_AMT, TRANSM_AMT
    
    transparency {
        filter FILTER_AMT
        transmit TRANSM_AMT
        blur {...}
    }
}
The *_AMT could be constants or functions.

Extend waveforms. spline_wave, function, move phase and frequency into 
"waveform" block. Default waveforms would be the same, but when a 
waveform block is specified, use unclipped pattern values as input.

finish_map, or let finish values be specified with functions.

Roll "sky_sphere" into "background". With the present name, too many 
people mistake it for an object.

RGBE file format support. Other high dynamic range formats.

axis_rotate, stretch transforms. axis_rotate is obvious, stretch is like 
scale, but along a specific axis. (axial_scale?)

I've mentioned my ideas for noise generators before...basically, they 
would be ordinary functions.

Dump the # character for anything not a "preprocessor" command.

I have a lot of other ideas, but I'll stop there.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message

Christopher James Huff <cja### [at] earthlinknet> wrote:
> Roll "sky_sphere" into "background". With the present name, too many 
> people mistake it for an object.

  Another handy feature for "background" would be support for a pigment
(instead of the current support for a single color).
  The pigment could be evaluated, for example, at <0,0,0> in the lower
left pixel of the image and <1,1,0> at the upper right pixel. The
functionality would be pretty similar to using the alpha channel (+ua),
but instead of blending to transparent, the image would blend to the
given pigment.

  One of the most useful applications for this would be to specify a bitmap
for the background (which is often requested by people).

-- 
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}//  - Warp -

Post a reply to this message

Warp wrote:
> 
> Christopher James Huff <cja### [at] earthlinknet> wrote:
> > Roll "sky_sphere" into "background". With the present name, too many
> > people mistake it for an object.
> 
>   Another handy feature for "background" would be support for a pigment
> (instead of the current support for a single color).
>   The pigment could be evaluated, for example, at <0,0,0> in the lower
> left pixel of the image and <1,1,0> at the upper right pixel. The
> functionality would be pretty similar to using the alpha channel (+ua),
> but instead of blending to transparent, the image would blend to the
> given pigment.
> 
>   One of the most useful applications for this would be to specify a bitmap
> for the background (which is often requested by people).

How would you contrain it to the view point of the camera?

-- 
Ken Tyler

Post a reply to this message

In article <3e89d9a7@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   One of the most useful applications for this would be to specify a bitmap
> for the background (which is often requested by people).

This would be handled by something else. Your definition only works for 
camera rays, it is meaningless for reflected or refracted rays. I can 
think of two (non-exclusive) possibilities: a post-process feature, and 
a programmable camera feature which lets you specify every detail of the 
camera...basically coding the pixel level tracing in POV code. Some 
built-in functions would be made available to make new cameras based on 
existing ones. In this case, you would use one of these functions and a 
pigment function to determine the final pixel color.

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: chr### [at] tagpovrayorg
http://tag.povray.org/

Post a reply to this message