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