POV-Ray : Newsgroups : povray.unofficial.patches : Some ideas about SDL enhancements Server Time
3 Jul 2024 06:15:04 EDT (-0400)
  Some ideas about SDL enhancements (Message 11 to 20 of 37)  
<<< Previous 10 Messages Goto Latest 10 Messages Next 10 Messages >>>
From: ABX
Subject: Re: Some ideas about SDL enhancements
Date: 2 Apr 2003 03:25:17
Message: <pf6l8vgj0hf1j09dqfhee960ogrekdi7r7@4ax.com>
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

From: Warp
Subject: Re: Some ideas about SDL enhancements
Date: 2 Apr 2003 14:10:57
Message: <3e8b35c1@news.povray.org>
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

From: Christopher James Huff
Subject: Re: Some ideas about SDL enhancements
Date: 2 Apr 2003 16:55:41
Message: <cjameshuff-1493A3.16560902042003@netplex.aussie.org>
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

From: Christopher James Huff
Subject: Re: Some ideas about SDL enhancements
Date: 2 Apr 2003 17:07:10
Message: <cjameshuff-485E68.17070602042003@netplex.aussie.org>
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

From: Warp
Subject: Re: Some ideas about SDL enhancements
Date: 2 Apr 2003 19:11:59
Message: <3e8b7c4e@news.povray.org>
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

From: Christopher James Huff
Subject: Re: Some ideas about SDL enhancements
Date: 2 Apr 2003 20:31:59
Message: <cjameshuff-C10F9C.20321202042003@netplex.aussie.org>
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

From: ABX
Subject: Re: Some ideas about SDL enhancements
Date: 3 Apr 2003 02:09:14
Message: <a5jn8vs8n8u2929ajl86cmjtbhsamdm4fh@4ax.com>
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

From: Mael
Subject: Re: Some ideas about SDL enhancements
Date: 3 Apr 2003 02:57:27
Message: <3e8be967@news.povray.org>
> 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

From: ABX
Subject: Re: Some ideas about SDL enhancements
Date: 3 Apr 2003 03:08:27
Message: <gbqn8v4293sd4i439efa48a5pi3cmu0n92@4ax.com>
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

From: Mael
Subject: Re: Some ideas about SDL enhancements
Date: 3 Apr 2003 03:34:42
Message: <3e8bf222$1@news.povray.org>
> 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

<<< Previous 10 Messages Goto Latest 10 Messages Next 10 Messages >>>

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.