What about making postprocess not part of POV-Ray but to write an external
utily?
POV-Ray would output some file containing all the neccesary information
(normal, depth, ...) and then the user could postprocess the image in any
way he wants using the PPL(postprocessing language) without having to
compile POV-Ray just to add another postprocess.

What do you think about this?

Post a reply to this message

In article <3d8cf389@news.povray.org>, "Simon Adameit" <gom### [at] gmxde> 
wrote:

> What about making postprocess not part of POV-Ray but to write an external
> utily?
> POV-Ray would output some file containing all the neccesary information
> (normal, depth, ...) and then the user could postprocess the image in any
> way he wants using the PPL(postprocessing language) without having to
> compile POV-Ray just to add another postprocess.

Having patterns, pigments, warps, functions, and information that can't 
easily be written to file (such as intersected object) is a huge 
advantage, and post-process filters can be automated with the scene 
description language. The post-process utilities would have to 
incorporate most of POV's code and be automatically run by the scene 
file to equal the flexibility.

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

news: chr### [at] netplexaussieorg...
> The post-process utilities would have to
> incorporate most of POV's code and be automatically run by the scene
> file to equal the flexibility.

One thing I'd like is to make Pov-ray export directly the depth information
as a separate image. Also, the ability to export a "mask" image could be
nice. Right now it can be done by assigning special textures to the scene
but of course it can become complicated. I'm currently compositing complex
scenes and I wish these features existed.

G.

--
**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters

Post a reply to this message

In article <chr### [at] netplexaussieorg> , 
Christopher James Huff <chr### [at] maccom>  wrote:

> Having patterns, pigments, warps, functions, and information that can't
> easily be written to file (such as intersected object) is a huge
> advantage, and post-process filters can be automated with the scene
> description language. The post-process utilities would have to
> incorporate most of POV's code and be automatically run by the scene
> file to equal the flexibility.

Not really.  You can already do every post-process effect in POV-Ray right
now.  It is just not always easy.

    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 <3d8dd453@news.povray.org>,
 "Thorsten Froehlich" <tho### [at] trfde> wrote:

> Not really.  You can already do every post-process effect in POV-Ray right
> now.  It is just not always easy.

Well, every current post-process effect, not every possible one. You can 
get position, normal, and of course color. You can approximate depth and 
ray direction, though they depend on the camera used. Precision is lost 
because everything has to be written to fixed point files with a max of 
16 bits per component, enough for most things but a potential filter 
killer. You also have to render the scene multiple times.
Also, some things would be rediculously slow, especially if the 
algorithm is too complex to do in pure functions and has to be done in 
scene description language.

And anyway, I was talking about the advantages of doing it in POV, 
either through functions and other tricks or a post-process feature, 
over an external program.

-- 
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 <chr### [at] netplexaussieorg> , 
Christopher James Huff <chr### [at] maccom>  wrote:

> Well, every current post-process effect, not every possible one.

No, every possible one! -- You remember what Warp keeps telling everybody
about the POV-SDL whenever the "not a universal scripting language" argument
comes up, don't you?

    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

Thorsten Froehlich <tho### [at] trfde> wrote:
> No, every possible one! -- You remember what Warp keeps telling everybody
> about the POV-SDL whenever the "not a universal scripting language" argument
> comes up, don't you?

  Well, there are problems which are mathematically unsolvable (and thus
also unsolvable with a Turing-strong language - meaning that it would take
an infinite amount of time to solve it).
  Also problems belonging to the NP set of problems are usually too
complex to solve in an acceptable amount of time and/or memory (which
usually means in practice that all possible combinations have to be
checked for the solution (or best solution) to be found, that is, an
exponential amount of cases). If we think about the image as being a
graph (where each pixel is a node connected to 4 or 8 adjacent pixels),
one can easily come up with such problems.

  So "every possible one" is not strictly true. :)

-- 
#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 <3d8e3587@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   Well, there are problems which are mathematically unsolvable (and thus
> also unsolvable with a Turing-strong language - meaning that it would take
> an infinite amount of time to solve it).
>   Also problems belonging to the NP set of problems are usually too
> complex to solve in an acceptable amount of time and/or memory (which
> usually means in practice that all possible combinations have to be
> checked for the solution (or best solution) to be found, that is, an
> exponential amount of cases). If we think about the image as being a
> graph (where each pixel is a node connected to 4 or 8 adjacent pixels),
> one can easily come up with such problems.
> 
>   So "every possible one" is not strictly true. :)

Well, what I really meant was every filter possible to do as a filter 
built-in to POV-Ray. It is "possible" to do any of these in POV-Script, 
it is just that some of them would be utterly impractical or just too 
difficult or slow.

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

Warp wrote:
>   So "every possible one" is not strictly true. :)

Geez, how can a post-process effect be possible if it cannot be
implemented in any acceptable way in any language? I would rather call
that an IMpossible post-process effect. But, sure, of course you should
never miss a chance to clutter up a discussion by perceiving a word
(such as the word "possible") in a way that is completely irrelevant in
the context at hand, and then, based on that, tell other people that
their statements were not quite entirely correct. I'm sure that your
post have brought us all much closer to a practical solution to the
original problem at hand.

Posting like these are almost as useless as those postings that only
complain about other people's postings without actually adding anything
useful (or even remotely interesting) to the discussion. I think that if
people have nothing to do but complain, they should rather not speak up
at all.

Followup-to povray.off-topic

Rune
--
3D images and anims, include files, tutorials and more:
rune|vision:  http://runevision.com (updated Sep 8)
POV-Ray Ring: http://webring.povray.co.uk

Post a reply to this message

"Christopher James Huff" wrote:
>
> Having patterns, pigments, warps, functions, and information that can't
> easily be written to file (such as intersected object) is a huge
> advantage, and post-process filters can be automated with the scene
> description language. The post-process utilities would have to
> incorporate most of POV's code and be automatically run by the scene
> file to equal the flexibility.
>
You are right I didn't think of that. But I would still like to have a
possibility to write my own post-processes.
I know that this can be done using the SDL but sometimes its just to slow.

Post a reply to this message