> 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