I know from the official 3.5 announcement that certain features
(motion_blur, blurred reflections, text object enhancements etc.) are
not going to be included in POV-Ray 3.5. I understand that these
features might not be stable enough or whatever to make it in to this
release. My question is has any discussion taken place about including
these features in any future release beyond 3.5? The text object
enhancements alone would be worth the price of admission <g>

Post a reply to this message

On Wed, 08 Aug 2001 17:24:17 -0400, Dave Dunn wrote:
>these features in any future release beyond 3.5? The text object
>enhancements alone would be worth the price of admission <g>

The text object "enhancements" aren't included because they're redundant.

-- 
#local R=<7084844682857967,0787982,826975826580>;#macro L(P)concat(#while(P)chr(
mod(P,100)),#local P=P/100;#end"")#end background{rgb 1}text{ttf L(R.x)L(R.y)0,0
translate<-.8,0,-1>}text{ttf L(R.x)L(R.z)0,0translate<-1.6,-.75,-1>}sphere{z/9e3
4/26/2001finish{reflection 1}}//ron.parker@povray.org My opinions, nobody else's

Post a reply to this message

"Ron Parker" <ron### [at] povrayorg> wrote in message
news:slr### [at] fwicom...
> On Wed, 08 Aug 2001 17:24:17 -0400, Dave Dunn wrote:
> >these features in any future release beyond 3.5? The text object
> >enhancements alone would be worth the price of admission <g>
>
> The text object "enhancements" aren't included because they're redundant.
>

    How so ?

--
Scott Hill.
Software Engineer.
E-Mail        : sco### [at] innocentcom
Pandora's Box : http://www.pandora-software.com

*Everything in this message/post is purely IMHO and no-one-else's*

Post a reply to this message

In article <3b71c1e0@news.povray.org> , "Scott Hill" <nos### [at] nospamthanks>
wrote:

>> The text object "enhancements" aren't included because they're redundant.
>
>     How so ?

The object bounds are sufficient to center text.  macros will be provided to
make it easier.

    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 in message
news:3b71c32f$1@news.povray.org...
> In article <3b71c1e0@news.povray.org> , "Scott Hill"
<nos### [at] nospamthanks>
> wrote:
>
> >> The text object "enhancements" aren't included because they're
redundant.
> >
> >     How so ?
>
> The object bounds are sufficient to center text.  macros will be provided
to
> make it easier.
>

    Yes, of course... Though, the text object enhancements seem the better
way to do it - keep the text alignment as a property of the text object...
It seems a little like removing light sources just because it's possible to
simulate what they do with high ambient objects and radiosity (that is, of
course, an extreme example, but do you see what I mean ?)... Not that it
really matters... I'll shut up now...

--
Scott Hill.
Software Engineer.
E-Mail        : sco### [at] innocentcom
Pandora's Box : http://www.pandora-software.com

*Everything in this message/post is purely IMHO and no-one-else's*

Post a reply to this message

In article <3b71c869$1@news.povray.org>,
 "Scott Hill" <nos### [at] nospamthanks> wrote:

>     Yes, of course... Though, the text object enhancements seem the better
> way to do it - keep the text alignment as a property of the text object...

Why is that good? Any object can be aligned, not just text objects.


> It seems a little like removing light sources just because it's possible to
> simulate what they do with high ambient objects and radiosity (that is, of
> course, an extreme example, but do you see what I mean ?)... Not that it
> really matters... I'll shut up now...

It is nothing like that. It is more like not including a light source 
type that only works on spheres.

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

"Chris Huff" <chr### [at] maccom> wrote in message
news:chr### [at] netplexaussieorg...
> In article <3b71c869$1@news.povray.org>,
>  "Scott Hill" <nos### [at] nospamthanks> wrote:
>
> >     Yes, of course... Though, the text object enhancements seem the
better
> > way to do it - keep the text alignment as a property of the text
object...
>
> Why is that good? Any object can be aligned, not just text objects.
>

    Oh, I'm not saying that the object bounds features should be removed and
the text alignment features kept. More that, alignment is a property of text
and it would seem to be more logical to have this ability built into the
text object... Imagine yourself as new POV user - you just want to get some
fancy textured text in your scene - you check out the docs on text, write
your script, and then think "Now I want that bit of text centered, that bit
left aligned and that other bit right aligned..." - with text alignment
commands the solution is obvious, without, it's not so obvious...

    Anyhow, it's not all that important, I just recall reading the text
alignment bit in the MegaPOV docs and thinking "Cool... a nice, easy, way to
align text...".

--
Scott Hill.
Software Engineer.
E-Mail        : sco### [at] innocentcom
Pandora's Box : http://www.pandora-software.com

*Everything in this message/post is purely IMHO and no-one-else's*

Post a reply to this message

On Thu, 9 Aug 2001 13:49:05 +0100, Scott Hill wrote:
>    Oh, I'm not saying that the object bounds features should be removed and
>the text alignment features kept. More that, alignment is a property of text
>and it would seem to be more logical to have this ability built into the
>text object... 

That seems true at first glance, but when you start investigating just how
many ways text can be aligned, it quickly starts looking like a daunting
task.  Left-aligned, right-aligned, center-aligned, right-justified, top or
bottom aligned, centered on all axes...  The operative philosophy is that
we prefer for those parts of the language that can be written in the language
be so done, because that makes things just as easy for the new user and more
extensible for the power user who doesn't happen to have a C++ compiler.

>Imagine yourself as new POV user - you just want to get some
>fancy textured text in your scene - you check out the docs on text, write
>your script, and then think "Now I want that bit of text centered, that bit
>left aligned and that other bit right aligned..." - with text alignment
>commands the solution is obvious, without, it's not so obvious...

Ideally, you just use the center/left/right/circular alignment macros that
are provided in the same way as colors.inc is now, and Robert's your dad's
brother.

-- 
plane{-z,-3normal{crackle scale.2#local a=5;#while(a)warp{repeat x flip x}rotate
z*60#local a=a-1;#end translate-9*x}pigment{rgb 1}}light_source{-9red 1rotate 60
*z}light_source{-9rgb y rotate-z*60}light_source{9-z*18rgb z}text{ttf"arial.ttf"
"RP".01,0translate-<.6,.4,.02>pigment{bozo}}light_source{-z*3rgb-.2}//Ron Parker

Post a reply to this message

Gawrsh, I seem to have touched off a huge argument about the nature of the text
object enhancements. I guess that particular example hit some resonant chord, which
was not my intent. The original question had to do more with the excluded features
(which I will not name for fear of a flareup <g>), and whether or not we could
expect to see them in a future release when they became more stable.

Post a reply to this message

On Thu, 09 Aug 2001 10:48:57 -0400, Dave Dunn wrote:
>
>Gawrsh, I seem to have touched off a huge argument about the nature of the text
>object enhancements. I guess that particular example hit some resonant chord, which
>was not my intent. The original question had to do more with the excluded features
>(which I will not name for fear of a flareup <g>), and whether or not we could
>expect to see them in a future release when they became more stable.

I think the plan is for no more 3.x versions after 3.5.  4.0 will be a complete
rewrite, so the chance of useful features being included is probably pretty 
high.

-- 
#macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z a-z)R(a
-z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F T)merge{
P(z+a)P(z-a)R(-z-z-x a)pigment{rgbf 1}hollow interior{media{emission 3-T}}}#end 
Z(-x-x.2x)camera{location z*-10rotate x*90normal{bumps.02scale.05}}

Post a reply to this message

Don't worry, my little friend. Nathan will save us all with a MegaPov 0.8
based on POV 3.5 with all those features.
Hope this makes you sleep. ;)

Post a reply to this message

JRG <jrg### [at] hotmailcom> wrote:
: MegaPov 0.8

  I'm waiting to see what will he do when 0.9 has been used and a new version
should be released... :)

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

>   I'm waiting to see what will he do when 0.9 has been used and a
new version
> should be released... :)

0.10 ? :-)

(Well thats the problem when I count, folders, for example:
files_1,files_2,...,files_9,files_10 - and now: sort it!)

cukk

Post a reply to this message

"Warp" wrote:
>   I'm waiting to see what will he do when 0.9 has
> been used and a new version should be released... :)

After 0.9.0 comes 0.10.0

...or the short version: after 0.9 comes 0.10

;)

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 <3b72ce3e@news.povray.org> , "JRG" <jrg### [at] hotmailcom> wrote:

> Don't worry, my little friend. Nathan will save us all with a MegaPov 0.8
> based on POV 3.5 with all those features.
> Hope this makes you sleep. ;)

I expect features that are redundant won't be future versions of MegaPOV
either...

    Thorsten

Post a reply to this message

Post Processing is redundant?!

"Thorsten Froehlich" <tho### [at] trfde> ha scritto nel messaggio
news:3b730b5c@news.povray.org...
> In article <3b72ce3e@news.povray.org> , "JRG" <jrg### [at] hotmailcom> wrote:
>
> > Don't worry, my little friend. Nathan will save us all with a MegaPov
0.8
> > based on POV 3.5 with all those features.
> > Hope this makes you sleep. ;)
>
> I expect features that are redundant won't be future versions of MegaPOV
> either...
>
>     Thorsten

Post a reply to this message

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

> Post Processing is redundant?!

Who said anything about post processing?
Thorsten only said redundant features (such as text object alignment) 
probably won't be included, which makes perfect sense. The post_process 
patch hadn't even been mentioned in this thread before your message.

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

Forget redundant, the update page says that it won't be included.
So perhaps there will be a way that Post Processing can be reintroduced
in a future 3.5 based MegaPOV.

Chris Huff wrote:
> 
> In article <3b73b3b2@news.povray.org>, "JRG" <jrg### [at] hotmailcom>
> wrote:
> 
> > Post Processing is redundant?!
> 
> Who said anything about post processing?

Post a reply to this message

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.

"Chris Huff" <chr### [at] maccom> ha scritto nel messaggio
news:chr### [at] netplexaussieorg...
> In article <3b73b3b2@news.povray.org>, "JRG" <jrg### [at] hotmailcom>
> wrote:
>
> > Post Processing is redundant?!
>
> Who said anything about post processing?
> Thorsten only said redundant features (such as text object alignment)
> probably won't be included, which makes perfect sense. The post_process
> patch hadn't even been mentioned in this thread before your message.
>
> --
> 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 <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.

  But the reason for not including post-processing is not that it's redundant.
  Redundancy is not the only reason for excluding features.

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

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

> 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?).

Exactly (this is along the lines I have been thinking).  There are numerous
benefits.  One would be that such an engine (or its framework, i.e. a simple
sample filter) could be distributed under a completely different license,
maybe real GPL or an even less restrictive license.  It would allow
everybody to write filters based on the output without having to deal with
the core code.  Those filters could be integrated into comfortable programs
and experimenting could be done realtime rather than the current and very
clumsy parse-render-postprocess method.  And, the POV-Team would not have to
integrate them immediately, etc, etc, etc...

    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:

>
> 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? ;-)

The only post-processing feature that I use is "Depth", which is extremely
useful when I need to work on the POV image in PhotoShop. Makes a lot of things
easier.

Tom Stone

Post a reply to this message

I agree with all of Thorsten's comments. I think this would be the
best future for POV-Ray post-processing.

Just to stir things up a little, does anyone want to create "import"
and "filter" plugins for Photshop (and compatible programs) that would
enable it to be used as a POV-Ray post-processor? Of course, you'll
need to make an "export" option for a custom version of POV-Ray, which
outputs a customized file type that supports all the raw POV-Ray data.


Remember, the Photoshop SDK is freely available and is fairly
cross-platform, if I'm not mistaken. There are also programs other
than Photoshop which support it.

Later,
Glen

Post a reply to this message

GIMP has a very powerful imaging engine that is fully script-able and it is 
GPL as well as xplatform.

Glen Berry wrote:

> I agree with all of Thorsten's comments. I think this would be the
> best future for POV-Ray post-processing.
> 
> Just to stir things up a little, does anyone want to create "import"
> and "filter" plugins for Photshop (and compatible programs) that would
> enable it to be used as a POV-Ray post-processor? Of course, you'll
> need to make an "export" option for a custom version of POV-Ray, which
> outputs a customized file type that supports all the raw POV-Ray data.
> 
> 
> Remember, the Photoshop SDK is freely available and is fairly
> cross-platform, if I'm not mistaken. There are also programs other
> than Photoshop which support it.
> 
> Later,
> Glen

Post a reply to this message

On Tue, 11 Sep 2001 16:54:50 +1000, Daniel Matthews <dan### [at] 3-enet>
wrote:

>GIMP has a very powerful imaging engine that is fully script-able and it is 
>GPL as well as xplatform.

I like GIMP. It's almost as good as Photoshop. (Please no stone
throwing from the Linux crowd.) However, I wonder if it supports
16-bit-per-color images? This would seem an advantage when doing
post-processing work. Of course, if it could be made to support
floating-point images, that would be even better.

One strong point in Photoshop's favor is its nearly universal
acceptance in the professional imaging community. It certainly
wouldn't hurt POV-Ray to be able to interact well with what is
probably the most respected photo-image editor in the world.


Later,
Glen

Post a reply to this message

Glen Berry <7no### [at] ezwvcom> wrote:
: However, I wonder if it supports 16-bit-per-color images?

  Nope, it doesn't seem to support them (unless a really recent version has
the addition...).

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

On Tue, 11 Sep 2001 05:20:07 -0400, Glen Berry wrote:
>On Tue, 11 Sep 2001 16:54:50 +1000, Daniel Matthews <dan### [at] 3-enet>
>wrote:
>
>>GIMP has a very powerful imaging engine that is fully script-able and it is 
>>GPL as well as xplatform.
>
>I like GIMP. It's almost as good as Photoshop. (Please no stone
>throwing from the Linux crowd.) 

Too bad Photoshop is an Adobe product (hack, spit.)

(My personal opinions only.)

-- 
#macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z a-z)R(a
-z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F T)merge{
P(z+a)P(z-a)R(-z-z-x a)pigment{rgbt 1}hollow interior{media{emission T}}finish{
reflection.1}}#end Z(-x-x.2y)Z(-x-x.4x)camera{location z*-10rotate x*90}

Post a reply to this message

Glen Berry wrote:

> I like GIMP. It's almost as good as Photoshop. (Please no stone
> throwing from the Linux crowd.) However, I wonder if it supports
> 16-bit-per-color images?

No, but yes.

There is a 'Hollywood' branch of the Gimp that has been hacked for 16-bit color
support.

http://film.gimp.org/

--
Wind the Frog!

Post a reply to this message