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

On Tue, 01 Apr 2003 21:58:55 -0500, Christopher James Huff
<cja### [at] earthlinknet> wrote:
> I can think of two (non-exclusive) possibilities: a post-process feature

already done for future MegaPOV

> and a programmable camera feature which lets you specify every detail of the 
> camera...basically coding the pixel level tracing in POV code.

already done for future MegaPOV in case user_defined camera type is enough
http://news.povray.org/search/?s=user_defined

> pigment function to determine the final pixel color.

In case you mean something like camera_view pigment, then such a thing is
already done for future MegaPOV

ABX

Post a reply to this message

Christopher James Huff <cja### [at] earthlinknet> wrote:
> Your definition only works for 
> camera rays, it is meaningless for reflected or refracted rays.

  If you read my article, I said that it would work in the same way
as the alpha channel (+ua) works.

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

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

> Christopher James Huff <cja### [at] earthlinknet> wrote:
> > Your definition only works for 
> > camera rays, it is meaningless for reflected or refracted rays.
> 
>   If you read my article, I said that it would work in the same way
> as the alpha channel (+ua) works.

Ok, but that doesn't really help. It's still nothing like the 
"background" or "sky_sphere" features.

Would a post_process filter that used the alpha channel to overlay the 
image over another do what you want?

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

In article <pf6l8vgj0hf1j09dqfhee960ogrekdi7r7@4ax.com>,
 ABX <abx### [at] abxartpl> wrote:

> > and a programmable camera feature which lets you specify every detail of 
> > the 
> > camera...basically coding the pixel level tracing in POV code.
> 
> already done for future MegaPOV in case user_defined camera type is enough
> http://news.povray.org/search/?s=user_defined

I doubt it, unless somebody else has worked up a more capable function 
language. I'm talking about something more like (roughly):

define BasicCamera = camera {...usual camera stuff...}

special_camera {
    function trace_pixel(x, y) {
        define pixelColor = BasicCamera.trace_pixel(x, y);
        return pixelColor + (1 - 
pixelColor.alpha)*bkgndPigment(x/image_width, y/image_height);
    }
}


> > pigment function to determine the final pixel color.
> 
> In case you mean something like camera_view pigment, then such a thing is
> already done for future MegaPOV

Again, highly doubtful. What I'm talking about would require something 
like my G project (now called Amber), which hasn't made it into a really 
useable state yet.

-- 
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:
> Would a post_process filter that used the alpha channel to overlay the 
> image over another do what you want?

  Yes, but adding a post-process engine for this purpose is overkill
(since it can be done in a pixel-by-pixel basis while rendering).

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

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

>   Yes, but adding a post-process engine for this purpose is overkill
> (since it can be done in a pixel-by-pixel basis while rendering).

It would be if it was only added for this one filter. If a post 
processing engine already exists, I think a post process filter is a 
better choice than a separate special-purpose feature.

And if one doesn't exist, I think adding one would still be a better 
idea. It solves more problems with less work than adding tons of little 
one-use features.

-- 
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 Wed, 02 Apr 2003 17:07:06 -0500, Christopher James Huff
<cja### [at] earthlinknet> wrote:
> I doubt it, unless somebody else has worked up a more capable function 
> language. I'm talking about something more like (roughly):
>
> define BasicCamera = camera {...usual camera stuff...}
>
> special_camera {
>   function trace_pixel(x, y) {
>    define pixelColor = BasicCamera.trace_pixel(x, y);
>    return pixelColor + (1 - 
>      pixelColor.alpha)*bkgndPigment(x/image_width, y/image_height);
>    }
> }
> > > pigment function to determine the final pixel color.

(Are you sure you used correct math for this effect? I used weighting.)

That's possible and already tested with my post_process implementation (if you
wish I can send sample image to p.b.i but its content seems obvious). It is
possible with following script.

  #version unofficial megapov 1.1;
  #include "pprocess.inc"

  Use_PP_Color_Output() // this macro turns on caching of color output and
                        // defines internal functions f_output_red,
                        // f_output_green, f_output_blue and f_output_alpha
                        // for further usage

  #declare back_Pig=function{pigment{agate}}; // pigment for background
  #declare f_avg=function(v1,v2,w){(1-w)*v1+w*v2}; // average/weight

  sphere{0 1 translate z*4 pigment{rgb 1}}
  light_source{-99 1}
  camera{}

  global_settings{
    post_process{
      // functions for four channels of output
      function{f_avg(f_output_red(x,y)  ,back_Pig(x,y,0).x,f_output_alpha(x,y))}
      function{f_avg(f_output_green(x,y),back_Pig(x,y,0).y,f_output_alpha(x,y))}
      function{f_avg(f_output_blue(x,y) ,back_Pig(x,y,0).z,f_output_alpha(x,y))}
      function{0}
      save_file "with_background.png"
    }
  }

Please note that there will be two passes, one for rendering and one for
post_process. But it will be also possible to do it in one pass. Instead of
using internal function with output of rendering you could use new camera_view
pigment type. The engine recognizes lack of output usage (it simple checks
whether output internal functions are defined in script). So rendering is
skipped (or rather does not use trace) and post_process loop starts. It is
possible and already tested with following script:

  #version unofficial megapov 1.1;
  #declare back_Pig=function{pigment{agate}}; // pigment for background
  #declare camb_Pig=function{pigment{camera_view{}  // rendering output
                            scale -y translate y}}; // has to be transformed
                                                    // like all image maps
  #declare f_avg=function(v1,v2,w){(1-w)*v1+w*v2}; // average/weight

  sphere{0 1 translate z*4 pigment{rgb 1}}
  light_source{-99 1}

  global_settings{
    post_process{
      // functions for four channels of output

function{f_avg(camb_Pig(x,y,0).x,back_Pig(x,y,0).x,camb_Pig(x,y,0).transmit)}

function{f_avg(camb_Pig(x,y,0).y,back_Pig(x,y,0).y,camb_Pig(x,y,0).transmit)}

function{f_avg(camb_Pig(x,y,0).z,back_Pig(x,y,0).z,camb_Pig(x,y,0).transmit)}
      function{0}
      save_file "with_background.png"
    }
  }

Please note that you have more control in this implementation than in your
script becouse you can define differend behaviour for each channel. In order to
avoid such long syntax for every scene you can simple collect your favourite
post_processes in macros (as it is done for replications of post_processing
effects used in previous MegaPovs) as well as in #declarations. Imagine:

  #macro PP_Clip_Colors(Color_Min,Color_Max)
    #local cminr=Color_Min.red;
    #local cmaxr=Color_Max.red;
    #local cming=Color_Min.green;
    #local cmaxg=Color_Max.green;
    #local cminb=Color_Min.blue;
    #local cmaxb=Color_Max.blue;
    #local cmina=Color_Min.transmit;
    #local cmaxa=Color_Max.transmit;
    function{clip(f_pp_red(u,v,-1)  ,cminr,cmaxr)}
    function{clip(f_pp_green(u,v,-1),cming,cmaxg)}
    function{clip(f_pp_blue(u,v,-1) ,cminb,cmaxb)}
    function{clip(f_pp_alpha(u,v,-1),cmina,cmaxa)}
  #end

  global_settings{
    post_process{ PP_Clip_Colors(rgb.1,rgb.9) }
  }

Moreover instead of refering to output data of rendering, you can refer one of
previous post_process effects. In below script in first effect channels are
reordered, in second effect they are inversed, in third effect they are
transformed:

  #version unofficial megapov 1.1;
  #include "pprocess.inc"
  Use_PP_Effects_Output() // defines internal functions f_pp_red, f_pp_green,  
                          // f_pp_blue and f_pp_alpha for further usage
  global_settings{
    post_process{
      function{f_output_green(x,y))} // green instead of red
      function{f_output_blue(x,y))}  // blue  instead of green
      function{f_output_red(x,y))}   // red   instead of blue
      function{f_output_alpha(x,y))} // transparency not changed
    }
    post_process{
      function{1-f_pp_green(x,y,1))} // inverse green
      function{1-f_pp_blue(x,y,1))}  // inverse blue
      function{1-f_pp_red(x,y,1))}   // inverse red
      function{f_pp_alpha(x,y,1))}   // transparency not changed
      save_file "inversed.png"
    }
    post_process{
      function{f_pp_green(x,1-y,2))} // mirror along y
      function{f_pp_blue(x,1-y,2))}  // mirror along y
      function{f_pp_red(x,1-y,2))}   // mirror along y
      function{f_pp_alpha(x,1-y,2))} // mirror along y
    }
  }

In above example there will be only two passes. One for rendering and one for
second effect. First effect if calculated online. Third effect is not calculated
because has no save_file parameter and is not used in any other effect.

Please note third parameter of f_pp_* functions. If positive it is index to
refer which previous effect should be calculated to get value. Index 0 means
original rendering output. Index negative is relative to current effect (simpler
when long list of effects is used).

I hope you like this new post_processing.

> > In case you mean something like camera_view pigment, then such a thing is
> > already done for future MegaPOV
>
> Again, highly doubtful.

In case you could deliver example script with description of expected image we
could clarify it.

ABX

Post a reply to this message

> I hope you like this new post_processing.

It seems promising ! Beside those f_output_ red green blue and alpha , what
other informations will be available (such as f_output_depth,
f_output_normal ..etc) ?

M

Post a reply to this message

On Thu, 3 Apr 2003 09:57:30 +0200, "Mael" <mae### [at] hotmailcom> wrote:
> > I hope you like this new post_processing.
>
> It seems promising ! Beside those f_output_ red green blue and alpha , what
> other informations will be available (such as f_output_depth,
> f_output_normal ..etc) ?

I duplicated chanels available in previous implementation of post_processing but
I have no idea whether they were all really used.

#declare f_output_red=function{internal(...)};
#declare f_output_green=function{internal(...)};
#declare f_output_blue=function{internal(...)};
#declare f_output_alpha=function{internal(...)};
#declare f_output_ipoint_x=function{internal(...)};
#declare f_output_ipoint_y=function{internal(...)};
#declare f_output_ipoint_z=function{internal(...)};
#declare f_output_inormal_x=function{internal(...)};
#declare f_output_inormal_y=function{internal(...)};
#declare f_output_inormal_z=function{internal(...)};
#declare f_output_pnormal_x=function{internal(...)};
#declare f_output_pnormal_y=function{internal(...)};
#declare f_output_pnormal_z=function{internal(...)};
#declare f_output_depth=function{internal(...)};
#declare f_output_u=function{internal(...)};
#declare f_output_v=function{internal(...)};
#declare f_pp_red=function{internal(...)};
#declare f_pp_green=function{internal(...)};
#declare f_pp_blue=function{internal(...)};
#declare f_pp_alpha=function{internal(...)};

But its definition is controlled by macros becouse it has to control caching
settings at the same time. In other words it is required to use pprocess.inc
include file just like functions.inc is dedicated for functions and mechsim.inc
is dedicated for mechanic simulations.

And of course usage of those functions before end of rendering cause error.

ABX

Post a reply to this message

> I duplicated chanels available in previous implementation of
post_processing

ok.
I don't know if it'd be easy to implement but it could be a plus to know
which object is intersected to allow postprocessing on limited part of the
output. Something like

sphere { ... object_id 1 }
box { ... object_id 2 }

f_output_iobject_id : return 1 if intersection is on the sphere, 2 for the
box..

M

Post a reply to this message

On Thu, 3 Apr 2003 10:34:46 +0200, "Mael" <mae### [at] hotmailcom> wrote:
> ok.
> I don't know if it'd be easy to implement but it could be a plus to know
> which object is intersected to allow postprocessing on limited part of the
> output. Something like
>
> sphere { ... object_id 1 }
> box { ... object_id 2 }
>
> f_output_iobject_id : return 1 if intersection is on the sphere, 2 for the
> box..

This shouldn't be a problem but I wonder whether this could be already
workarounded with combination of depth output + _your_ projection (point) patch.
But of course when more objects is used 'id' is much more useful.

ABX

Post a reply to this message

On Thu, 03 Apr 2003 09:08:14 +0200, ABX <abx### [at] abxartpl> wrote:
> But it will be also possible to do it in one pass. Instead of
> using internal function with output of rendering you could use new camera_view
> pigment type.

It should be noted that neither camera_view pigment nor post_process effects has
resolution like image_map. They are contignous from <0,0> to <1,1> but of course
values taken from rendering output are pixelized. In order to get camera_view
and effects "pixelized" (integer coordinates on image) we have to use (delivered
but simple) functions to convert. Having contignous coordinates seems much
better since now we can experiment with other antialiasing without patching
sources. In other words AA become part of post_processing instead of rendering
(and when you wish only part of image can be antialiased with only necessary
amount of rays traced).

ABX

Post a reply to this message

> Having contignous coordinates seems much better since now
> we can experiment with other antialiasing without patching sources.

In case you're looking for an example, what about trying a Mitchell and
Netravali filter which seems to be used in some renderers. It takes two
parameters blur/ringing

M

Post a reply to this message

On Thu, 3 Apr 2003 11:41:05 +0200, "Mael" <mae### [at] hotmailcom> wrote:
> > Having contignous coordinates seems much better since now
> > we can experiment with other antialiasing without patching sources.
>
> In case you're looking for an example, what about trying a Mitchell and
> Netravali filter which seems to be used in some renderers. It takes two
> parameters blur/ringing

I will leave it for future users because I already hardly find free time for
other opened tasks.

ABX

Post a reply to this message

In article <a5jn8vs8n8u2929ajl86cmjtbhsamdm4fh@4ax.com>,
 ABX <abx### [at] abxartpl> wrote:

> (Are you sure you used correct math for this effect? I used weighting.)

I didn't, but I wasn't really concerned with that, since the syntax 
itself is so rough.

define BasicCamera = camera {...usual camera stuff...}
function lerp(mn, mx, t) {return mn*t + mx*(1-t);}

special_camera {
    function trace_pixel(x, y) {
        //get the raw color of the pixel
        def pixelColor = BasicCamera.trace_pixel(x, y);
        
        //The result is a linear interpolation between the raw color
        //and the background, controlled by the alpha channel.
        def result = lerp(pixelColor, bkgndPigment(x/image_width, 
y/image_height, 0), pixelColor.alpha);
        
        //That calculation modified alpha, so set it back to normal
        result.alpha = pixelColor.alpha;
        
        //do I need to explain?
        return result;
    }
}


> That's possible and already tested with my post_process 
> implementation (if you wish I can send sample image to p.b.i but its 
> content seems obvious). It is possible with following script.

You seem to miss the point completely. I'm not talking about a post 
process feature, isn't that obvious? This is a way to specify the camera 
behavior at a very low level. That trace_pixel() function is called by 
POV to trace every pixel.


>   #declare f_avg=function(v1,v2,w){(1-w)*v1+w*v2}; // average/weight

Eh...this is linear interpolation, not any kind of average. A common 
name seems to be "lerp", though I don't know why, I usually use 
something like linInterp. Anyway, there should be a function already 
defined which does this...and it is unrelated to the subject of this 
thread.


>   global_settings{
>     post_process{
>       // functions for four channels of output
>       function{f_avg(f_output_red(x,y)  
>       ,back_Pig(x,y,0).x,f_output_alpha(x,y))}
>       function{f_avg(f_output_green(x,y),back_Pig(x,y,0).y,f_output_alpha(x,y)
>       )}
>       function{f_avg(f_output_blue(x,y) 
>       ,back_Pig(x,y,0).z,f_output_alpha(x,y))}
>       function{0}
>       save_file "with_background.png"
>     }
>   }

Sorry, but yuck. This is something that really needs vector functions, 
and IMO should wait until they are available because it will need to be 
redesigned and rewritten when they are here.


> Please note that you have more control in this implementation than in your
> script becouse you can define differend behaviour for each channel.

Wrong. My script only handled all channels at once because that was all 
that was needed. It could easily handle channels separately.


> I hope you like this new post_processing.

Sorry, I don't. Great improvement in functionality, but extreme loss in 
useability and efficiency. As I said, this really, really needs vector 
functions. Using n-tuples of functions makes things far more complex 
than necessary, and requires recomputing things that could be done once. 
your "one-pass" version calls camb_Pig() 6 times and back_Pig() 3 times 
per pixel, when once each would do. It also takes three functions whcih 
have only 2 characters that change, when one function of about the same 
length would do.

-- 
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 Thu, 03 Apr 2003 10:08:48 -0500, Christopher James Huff
<cja### [at] earthlinknet> wrote:
> > That's possible and already tested with my post_process 
> > implementation (if you wish I can send sample image to p.b.i but its 
> > content seems obvious). It is possible with following script.
>
> You seem to miss the point completely. I'm not talking about a post 
> process feature, isn't that obvious?

No. You have described some functionality you dream about and I showed you how
it could be possible with my patch.

> >   global_settings{
> >     post_process{
> >       // functions for four channels of output
> >       function{f_avg(f_output_red(x,y),back_Pig(x,y,0).x,f_output_alpha(x,y))}
> >       function{f_avg(f_output_green(x,y),back_Pig(x,y,0).y,f_output_alpha(x,y))}
> >       function{f_avg(f_output_blue(x,y),back_Pig(x,y,0).z,f_output_alpha(x,y))}
> >       function{0}
> >       save_file "with_background.png"
> >     }
> >   }
>
> Sorry, but yuck. This is something that really needs vector functions, 
> and IMO should wait until they are available because it will need to be 
> redesigned and rewritten when they are here.

So do you want me to remove it from from MegaPOV 1.1 ? Do you prefer the
previous much more limited post_processing ? Or do you want to deliver vector
functions within a month ? I do not understand your intentions. I do not think
community want to wait years for post processing.

> > Please note that you have more control in this implementation than in your
> > script becouse you can define differend behaviour for each channel.
>
> Wrong. My script only handled all channels at once because that was all 
> that was needed. It could easily handle channels separately.

Can you deliver sources for inclusion in compilation ?

> > I hope you like this new post_processing.
>
> Sorry, I don't. Great improvement in functionality, but extreme loss in 
> useability and efficiency. As I said, this really, really needs vector 
> functions. Using n-tuples of functions makes things far more complex 
> than necessary, and requires recomputing things that could be done once. 
> your "one-pass" version calls camb_Pig() 6 times and back_Pig() 3 times 
> per pixel, when once each would do. It also takes three functions whcih 
> have only 2 characters that change, when one function of about the same 
> length would do.

I completly understand your point here but the problem is that I do not have
vector functions available. And I can hardly see when they will be available.
But once the sources will be available you can improve it, I will be happy about
that.

ABX

Post a reply to this message

In article <3e8bf222$1@news.povray.org>, "Mael" <mae### [at] hotmailcom> 
wrote:

> I don't know if it'd be easy to implement but it could be a plus to know
> which object is intersected to allow postprocessing on limited part of the
> output. Something like
> 
> sphere { ... object_id 1 }
> box { ... object_id 2 }
> 
> f_output_iobject_id : return 1 if intersection is on the sphere, 2 for the
> box..

A better idea might be some group label.

sphere { ... object_groups "mask A", "mask B" }
box { ... object_groups "high AA" }

And then have exclude_groups and include_groups options for the filters, 
and/or filters that use the groups for other things like masks.

Hmm, a shorter possible alternate syntax:

sphere { ... }: "mask A", "mask B"
box { ... }: "high AA"

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

In article <2dko8v0n8gi53kla520aca3au0ltl163a8@4ax.com>,
 ABX <abx### [at] abxartpl> wrote:

> > You seem to miss the point completely. I'm not talking about a post 
> > process feature, isn't that obvious?
> 
> No. You have described some functionality you dream about and I showed you 
> how it could be possible with my patch.

I used this specific example to describe some functionality I've long 
wanted and done some work on implementing, and you gave a completely 
different way to do the same thing. It still has nothing to do with the 
features I described, which is a way to specify some code for POV to run 
to do something that would normally be hard-coded.


> So do you want me to remove it from from MegaPOV 1.1 ?

I think you should definitely consider it. I'm pretty sure a public vote 
would be in favor of its inclusion, but keep in mind the changes you 
would have to make later to the patch and the support of people whose 
scene files no longer work.


> Do you prefer the previous much more limited post_processing ?

I prefer its syntax, though not its limitations.


> Or do you want to deliver vector functions within a month ? I do not 
> understand your intentions. I do not think community want to wait 
> years for post processing.

I posted an early version of my G patch in povray.binaries.programming. 
It is not fully working and the VM isn't as sophisticated as Thorsten's, 
but would be of great help in any programmable features.
Within a month? Probably not, I'll be busy with the end of the semester. 
If someone had asked, I might have put more work into it. But it would 
be easy to prepare for them.


> > Wrong. My script only handled all channels at once because that was all 
> > that was needed. It could easily handle channels separately.
> 
> Can you deliver sources for inclusion in compilation ?

Of course not. As I said, that was just an example of a possible syntax, 
the patch does not exist yet.


> I completly understand your point here but the problem is that I do not have
> vector functions available. And I can hardly see when they will be available.
> But once the sources will be available you can improve it, I will be happy 
> about that.

Vector functions are available, in the form of pigment functions. Code 
that uses pigment functions will be compatible with future vector 
function additions. A more robust solution might be to use vector 
functions and make a triple-function pigment or vector function (so 
people don't have to mess around with averaging multiple pigments).

BTW, will the next MegaPOV fix the name of the solid pattern?

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

In article <cja### [at] netplexaussieorg> , 
Christopher James Huff <cja### [at] earthlinknet>  wrote:

> A better idea might be some group label.
>
> sphere { ... object_groups "mask A", "mask B" }
> box { ... object_groups "high AA" }

For suggesting this syntax you deserve to be shot! ;-)

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <3e8dcf10$1@news.povray.org>,
 "Thorsten Froehlich" <tho### [at] trfde> wrote:

> > sphere { ... object_groups "mask A", "mask B" }
> > box { ... object_groups "high AA" }
> 
> For suggesting this syntax you deserve to be shot! ;-)

That wasn't really a fully-formed feature suggestion, just a quick, 
half-baked example of how it might look.
Anyway, what exactly is your objection? The string group IDs? Since a 
group isn't really a thing, I wasn't sure about giving it an actual 
identifier. It could be done and might look cleaner, it just might 
unexpectedly clash with variable or macro names.
Or is your complaint with the group idea itself? It was suggested as an 
improvement to the "object ID" idea, and seems much better to me. Got a 
better idea?

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

In article <cja### [at] netplexaussieorg> , 
Christopher James Huff <cja### [at] earthlinknet>  wrote:

> Anyway, what exactly is your objection? The string group IDs?

Yes.  Remember light groups?  They implemented something similar alien to
the language.

> Or is your complaint with the group idea itself? It was suggested as an
> improvement to the "object ID" idea, and seems much better to me. Got a
> better idea?

Sure, but you would need to extend several parts of the language to do it
properly ... there are simply things you cannot do without ugly hacks in the
3.x implementation of POV-Ray.  This is one of them.  And rather than a
hack, not doing it is the responsible choice.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

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

> Yes.  Remember light groups?  They implemented something similar alien to
> the language.

I vaguely remember. I haven't done much with either version of that 
patch, but I recall the original one using string labels, and the new 
one didn't, which I considered an improvement.


> Sure, but you would need to extend several parts of the language to do it
> properly ... there are simply things you cannot do without ugly hacks in the
> 3.x implementation of POV-Ray.  This is one of them.  And rather than a
> hack, not doing it is the responsible choice.

Out of curiousity, what hacks are you thinking of? I can't think of any 
difficulties offhand, but I haven't tried to actually implement it.

One thing that might be worth considering is a standardized grouping 
syntax, something that can be used for light groups, post process 
filters, and anything else that could benefit. Is this the type of thing 
you're talking about?

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

> In article <3e889ec9@news.povray.org>, Warp <war### [at] tagpovrayorg> wrote:
>>   * Array operators for the string type.
> 
> And splines. Unify splines with the ones used by shapes like lathe and
> prism too.

This is on my personal to-do list.  Maybe one of these days I'll actually
get around to it.

-- 
Mark

Post a reply to this message

On Tue, 08 Apr 2003 03:27:26 -0400, Mark Wagner <mar### [at] gtenet> wrote:
> > And splines. Unify splines with the ones used by shapes like lathe and
> > prism too.
>
> This is on my personal to-do list.  Maybe one of these days I'll actually
> get around to it.

Have you some universal solution in mind or each new type will require set of
methods? Will be new spline types handled (magicaly) automatically? I made new
sor_spline available and I'm working on some other spline types.

ABX

Post a reply to this message

ABX <abx### [at] abxartpl> wrote:
> Have you some universal solution in mind or each new type will require set of
> methods? Will be new spline types handled (magicaly) automatically? I made new
> sor_spline available and I'm working on some other spline types.

  I suppose that the only solution for now is to allow only compatible
splines to be used in sors and lathes (and an error message would be issued
if an incompatible type is used).

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

On Tue, 08 Apr 2003 06:59:13 -0400, ABX quoth:

> On Tue, 08 Apr 2003 03:27:26 -0400, Mark Wagner <mar### [at] gtenet>
> wrote:
>> > And splines. Unify splines with the ones used by shapes like lathe
>> > and prism too.
>>
>> This is on my personal to-do list.  Maybe one of these days I'll
>> actually get around to it.
> 
> Have you some universal solution in mind or each new type will require
> set of methods? Will be new spline types handled (magicaly)
> automatically? I made new sor_spline available and I'm working on some
> other spline types.

To convert from a pure spline to a lathe or prism spline, you'd specify
which two coordinate axes you want, using the normal x/y/z r/g/b/f/t
symbols.  Natural cubic splines would be converted to catmull-rom cubics,
and a warning message printed.  I haven't figured out what the syntax for
going from objects to pure splines would be yet.

e.g. prism{ MyLinearSpline x,y linear_sweep 0, 1} uses the x and y
coordinates of the spline from MyLinearSpline as the shape of the prism.

-- 
Mark

Post a reply to this message

In article <pan### [at] gtenet>,
 Mark Wagner <mar### [at] gtenet> wrote:

> I haven't figured out what the syntax for going from objects to pure 
> splines would be yet.

If you mean taking an object like a lathe or prism and getting a spline 
from it, I think that is unnecessary. If you can specify the object, you 
can specify the spline and pass it to the object while keeping it for 
later use.

The internal handling of splines could also use some work...I doubt any 
major changes to internal structures would be in any future version 
though. (Disclaimer: This is my personal judgement, not an official 
statement...but everything that has been said indicates that the next 
major update will be POV 4.)

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