In article <3b7528fc@news.povray.org>, "JRG" <jrg### [at] hotmailcom> 
wrote:

> But, IIRC, it won't be included in POV 3.5. The thread was about features
> which aren't going to be included in the official version of pov.

Nope, Thorsten quite clearly was talking about MegaPOV.

And the post_process feature won't be included in POV 3.5, not because 
it is redundant, but because it simply wasn't ready. Nobody said it 
wasn't going to be in MegaPOV either.

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

<><

Post a reply to this message

"JRG" wrote:
> Yet I can't understand why post_process won't be included
> (but I'm sure you'll enlighten me ;) ).

The current post_process is a mess IMHO.

The syntax for the various effects vary greatly, many of the effects aren't
resolution independent, and there is no way to create user-defined filters,
so the user is stuck with the filters available.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated June 26)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

Good to know, but that's just what I was saying.
As an aside: was that bug concerning sphere-sweep and radiosity fixed?

--
Jonathan

Post a reply to this message

JRG <jrg### [at] hotmailcom> wrote:
: As an aside: was that bug concerning sphere-sweep and radiosity fixed?

  Which bug?

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message

In article <3b766cc8@news.povray.org> , "Rune" <run### [at] mobilixnetdk>
wrote:

> The current post_process is a mess IMHO.

Yes it is :-(

> The syntax for the various effects vary greatly, many of the effects aren't
> resolution independent, and there is no way to create user-defined filters,
> so the user is stuck with the filters available.

Am I the only person who has the impression it is also a convenient way to
get around the post-processing rules of the IRTC? ;-)

Anyway, IMO a much better solution would be to write the additional data to
a file and then let users post-process it outside POV-Ray.  (How exactly
this would be done is not the point here.)

    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" wrote:
> Anyway, IMO a much better solution would be to write
> the additional data to a file and then let users
> post-process it outside POV-Ray.

I agree.

However, how many times larger would such a file be than a regular image? I
mean, floating point unclipped values for both color, normal, depth, etc.
could take up quite some space...

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated June 26)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

In article <3b768062@news.povray.org>,
 "Thorsten Froehlich" <tho### [at] trfde> wrote:

> Am I the only person who has the impression it is also a convenient way to
> get around the post-processing rules of the IRTC? ;-)

I don't think it is. I always thought the rules against post-processing 
were to avoid "hand editing"...not stuff like gamma adjustment or focal 
blur.


> Anyway, IMO a much better solution would be to write the additional data to
> a file and then let users post-process it outside POV-Ray.  (How exactly
> this would be done is not the point here.)

This would be impossible (or just unnecessarily difficult) for most 
people to make any use of, and a real pain for animation or for 
post_process's controlled by the POV scene. I don't know of any standard 
formats for this kind of data or software for dealing with it, users 
would have to write their own or rely on others...and many of them would 
be far more difficult to write independant of POV.

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

<><

Post a reply to this message

In article <3b768325@news.povray.org> , "Rune" <run### [at] mobilixnetdk>
wrote:

> However, how many times larger would such a file be than a regular image? I
> mean, floating point unclipped values for both color, normal, depth, etc.
> could take up quite some space...

Well, it would be better to hold all the data on disk rather than in memory
(!!!) as it is now...

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

>>   (How exactly
>> this would be done is not the point here.)
>
> This would be impossible (or just unnecessarily difficult)

As I said "How exactly this would be done is not the point here." -- it is
the short and nice way of saying I don't want to get into a 4.0 feature
discussion here and now ;-)

    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

Imagine the following solution:

To enable a "full data" format (unclipped floating point values for color,
normal, depth etc.) you would write a special keyword in the global_settings
block or maybe specify it in the command line.

Together with the POV-Ray raytracer engine would be a post-process engine.
You control post-processing through a separate and very simple scripting
language which you write in separate files with a different extension
(.ppp?).

You could use the pp-engine in at least two ways:

1) You could call it from within your POV-script file (by specifying it in
global_settings). This way the PP-script would be automatically run after an
image is rendered, or after each frame in an animation are rendered.

2) You could run it directly. This would require that you'd somehow specify
which input images (in "full data" format) to process.

programmers could also write their own pp-engines that would read and
process "full data" files.

Also, in the raytracing engine could be a command-line switch to disable
rendering (so only parsing is done). That way you could render an image or
animation once (with post-processing), and if you find out you want to make
changes in the post-processing you could render it several times with
different post-process options without having to re-raytrace every time.

You could even use the I/O features in POV-Ray to write the pp-script (or
parts of it) and pass on variables to it that way.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated June 26)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message