hi,

in megapov 0.7, are the color channels FILTER and TRANSM correct in post
process functions ?

i m trying to write my simple post process, background_pigment, and i d like
to use either the filter channel either the transm channel.. So i first try
to replace pixel with a non zero filter channel with my pigment (see code),
but it doesn t seem to work fine, i just get one line where it s ok (i don t
know why just this line in the middle of my example..) . In atmosph.c i've
also commented out two lines in Do_Infinite_Atmosphere (colour[filter]=0..)
but it changes nothing. After this, i ve tried with the transm component,
but it only works in the background and only if +UA is set :(

here is the code for the post process and a pov example in case someone can
see my mistake.. thanks



void doPostBackgroundPigment(PP_TASK *pp_task, COLOUR **in, COLOUR **out,
PP_DATA_LISTS data, int height, int width)
{
  int x,y;
  PP_BACKGROUND_PIGMENT * Task;

  COLOUR Weight;
  VECTOR Loc;

  Task = (PP_BACKGROUND_PIGMENT *)pp_task;

  PP_STATUS_BEGIN("background_pigment")
  for(y=0; y<height; y++)
  {
    PP_STATUS_PROGRESS("background_pigment")
    COOPERATE_1
    for(x=0; x<width; x++)
    {
      if (in[y][x][3])
      {
        Loc[0] = (DBL)x/width;
        Loc[1] = (DBL)y/height;
        Loc[2] = 0;
        Compute_Pigment (Weight, Task->Pig, Loc, NULL);
        out[y][x][0]=Weight[0];
        out[y][x][1]=Weight[1];
        out[y][x][2]=Weight[2];
        out[y][x][3]=in[y][x][3];
        out[y][x][4]=in[y][x][4];
      }
      else
      {
        out[y][x][0]=in[y][x][0];
        out[y][x][1]=in[y][x][1];
        out[y][x][2]=in[y][x][2];
        out[y][x][3]=in[y][x][3];
        out[y][x][4]=in[y][x][4];
      }
    }
  }
  PP_STATUS_END
}


#version unofficial MegaPov 0.7;

global_settings
{
 ini_option "+A +UA"
 post_process { background_pigment { checker color rgb 1 color rgb 0 scale
.1} }
}

background { color rgbft<0,0,0,1,1> }

camera { location <1,1, -6> look_at <0, 1, 0> }

plane { y, 0 pigment { color rgb <.9,.3,.7>}}
sphere { <1,1,0>, 1 pigment { color rgbft <.4,.5,.7,.4,0> }}
sphere { <-2,2,.4> , 1 pigment { color rgbft <.3,.5,.5,.2,0> }}
light_source { <10, 10, -10>, color rgb 1 }

Post a reply to this message

In article <3aacc0a0@news.povray.org>, "Mael" <Mae### [at] hotmailcom> 
wrote:

> in megapov 0.7, are the color channels FILTER and TRANSM correct in 
> post process functions ?

I'm not sure what you expect them to do...they don't really have any 
meaning in the output image. Well, I think one of them is used for the 
alpha value, but I don't think that will help you, unless you want to 
destroy transparent objects through which the background is visible. Try 
checking the depth value instead...if you want to change transparent 
objects, remember that alpha is the opposite of filter or transmit, it's 
an opacity value, where 1 is completely opaque and 0 is transparent.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

>
> I'm not sure what you expect them to do...they don't really have any
> meaning in the output image. Well, I think one of them is used for the
> alpha value, but I don't think that will help you, unless you want to
> destroy transparent objects through which the background is visible. Try
> checking the depth value instead...if you want to change transparent
> objects, remember that alpha is the opposite of filter or transmit, it's
> an opacity value, where 1 is completely opaque and 0 is transparent.

i ve seen you used the depth information in your stars post process, but
here i would like to see the "background_pigment" given by the user through
transparent objects (by blending(not sure this is the term in english?) rgb
of the specified pigment with the rgb of the object)

i thought the channel filter (or transmit) could be used for that, but it
doesn t seem to work as i expected :(

M

Post a reply to this message

In article <3aacc0a0@news.povray.org> , "Mael" <Mae### [at] hotmailcom> 
wrote:

> here is the code for the post process and a pov example in case someone can
> see my mistake..

I suggest you add this feature to "background { }" rather than to an
output filter.


    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 <3aacf1b7$1@news.povray.org>, "Mael" <Mae### [at] hotmailcom> 
wrote:

> i ve seen you used the depth information in your stars post process, 
> but here i would like to see the "background_pigment" given by the 
> user through transparent objects (by blending(not sure this is the 
> term in english?) rgb of the specified pigment with the rgb of the 
> object)

I see...well, it might work, but remember that it won't be correct with 
refracting surfaces, and it still won't work for reflections.


> i thought the channel filter (or transmit) could be used for that, but it
> doesn t seem to work as i expected :(

Well, remember that alpha is the opposite of transmit...if you were 
checking for non-0 values, you were checking for any values that 
*weren't* completely transparent. With alpha, 0 is completely 
transparent and 1 is completely opaque.
And from the documentation, it looks like POV uses the transmit channel 
to get alpha information...post_process data may be the same.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

> I suggest you add this feature to "background { }" rather than to an
> output filter.

the problem with background{ } is that i don t have screen coordinates
information for non primary rays, so i don t know where to compute the
pigment ..

M

Post a reply to this message

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

> the problem with background{ } is that i don t have screen coordinates
> information for non primary rays, so i don t know where to compute the
> pigment ..

???  This information is not available to you if you use post-processing
either.  I don't understand your point, trace_pixel (in render.c) has
the screen coordinates you need, so there is absolutely no problem.


     Thorsten

Post a reply to this message

> I don't understand your point, trace_pixel (in render.c) has
> the screen coordinates you need, so there is absolutely no problem.

right ! i'll try to add this in trace_pixel

my problem was due to the fact that i was trying to add the compute
background pigment in Do_Infinite_Atmosphere (simply because it's where
Frame.Background_Colour is used). However this function can be called for
refracted or reflected rays, where there is no more screen coordinates ..
(sorry for my pathetic english..)

by the way , while looking at pov source code i notice a huge switch/case in
pattern.c (in Evaluate_TPat). Wouldn t it be faster if a pointer of function
was used ? i think the evaluate_tpat is called very often so any
optimization could result in faster rendering

M

Post a reply to this message

On Tue, 13 Mar 2001 16:15:53 +0100, Mael wrote:
>by the way , while looking at pov source code i notice a huge switch/case in
>pattern.c (in Evaluate_TPat). Wouldn t it be faster if a pointer of function
>was used ? i think the evaluate_tpat is called very often so any
>optimization could result in faster rendering

A good compiler will optimize that to a table if a table would be faster.
f'ups to .programming.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message