From the megaDoc:

"Note:  The ini_option will probably be discontinued in the future."

Why is this?

Ingo

-- 
Photography: http://members.home.nl/ingoogni/
Pov-Ray    : http://members.home.nl/seed7/

Post a reply to this message

ingo <ing### [at] homenl> wrote:
: "Note:  The ini_option will probably be discontinued in the future."

: Why is this?

  I don't know the reason, but I can imagine a couple of them:

  - Security.
  - The type of rendering (size, antialiasing, etc) should specified outside
the scene, not inside.
  Just imagine the annoyance of a scene with "-w1280 -h1024 +a0.0 +qr" when
you just want to render a quick preview of it. You would have to edit the
scene by hand before being able to do it. It would also make trouble to a
possible software which automatically renders a set of scenes with certain
settings (for thumbnails, for example).

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Nieminen Juha wrote:

>ingo <ing### [at] homenl> wrote:
>: "Note:  The ini_option will probably be discontinued in the future."

>  I don't know the reason, but I can imagine a couple of them:
>  - Security.

With the shell-out options not included, I don't see any problem here.

>  - The type of rendering (size, antialiasing, etc) should specified
>  outside the scene, not inside.
>  Just imagine the annoyance of a scene with "-w1280 -h1024 +a0.0 +qr"
>  when you just want to render a quick preview of it. 

That little annoyance, I allready have without the ini_options. Switching from 
one scene to another and then wonder why it takes so long to render. Argh, 
forgot to change the commandline options (windows pov). 
That's why I prefer the in file ini_option, especialy with files that use the 
new radiosity setting or a non 4:3 aspect ratio. No more changing commanline 
options and forgetting them or editing (scene specific) ini files.

>  It would also make trouble to a possible software which automatically
>  >  renders a set of scenes with certain settings (for thumbnails, for
>  example). 

Agree, didn't think of that.


Ingo

-- 
Photography: http://members.home.nl/ingoogni/
Pov-Ray    : http://members.home.nl/seed7/

Post a reply to this message

Nieminen Juha wrote:
> 
> ingo <ing### [at] homenl> wrote:
> : "Note:  The ini_option will probably be discontinued in the future."
> 
> : Why is this?
> 
>   I don't know the reason, but I can imagine a couple of them:
> 
>   - Security.
>   - The type of rendering (size, antialiasing, etc) should specified outside
> the scene, not inside.
>   Just imagine the annoyance of a scene with "-w1280 -h1024 +a0.0 +qr" when
> you just want to render a quick preview of it. You would have to edit the
> scene by hand before being able to do it. It would also make trouble to a
> possible software which automatically renders a set of scenes with certain
> settings (for thumbnails, for example).

The latter seams to me more a question of relative priorities between
command line, ini file and scene file. The thumbnails question is not
relevant in this case.

OTOH being able to determine the size of a picture at render time can be
useful for special applications like automatic rendering of ttf fonts
samples.

Just my $0.02.

-- 
François DISPOT  --  http://www.wozzeck.net
      __  __ __  __  _
|  | /  \  /  / |_  /  |/
\/\/ \__/ /_ /_ |__ \_ |\

Post a reply to this message

Francois Dispot <woz### [at] club-internetfr> wrote:
: OTOH being able to determine the size of a picture at render time can be
: useful for special applications like automatic rendering of ttf fonts
: samples.

  You don't need ini_option for this.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

On 6 Feb 2000 08:56:37 -0500, ing### [at] homenl (ingo) wrote:

>That little annoyance, I allready have without the ini_options. Switching from 
>one scene to another and then wonder why it takes so long to render. Argh, 
>forgot to change the commandline options (windows pov). 
>That's why I prefer the in file ini_option, especialy with files that use the 
>new radiosity setting or a non 4:3 aspect ratio. No more changing commanline 
>options and forgetting them or editing (scene specific) ini files.
>

For what it's worth, I have wanted to specify the height and width of
an image from within a POV scene file since version 2.2, if not
earlier than that. The "ini_option" feature is one of my favorite
features. I'm not sure why it might be taken out in the future.

If someone is afraid of some "rogue" scene file having  too much
control of their computer, why not just make the settings on the
command line and/or the "povray.ini" file overide the settings made by
"ini_option." The settings suggested by "ini_option" would only take
effect if there were no "default" or overiding value set by either the
command line or the "povray.ini" file.

For those of us that like to specify ini options in the scene file, we
could simply leave empty spaces in our povray.ini files and carry on
as usual. Those that didn't like scene files having control, could
insert default values in their povray.ini, and they could likewise
carry on as usual.

Would there be any problems with this arrangement? I'd *really* like
to keep "ini_option" in the POV-Ray scene file.

thanks,
Glen Berry

Post a reply to this message

Seconded

Glen Berry wrote:
> 
>
> 
> For those of us that like to specify ini options in the scene file, we
> could simply leave empty spaces in our povray.ini files and carry on
> as usual. Those that didn't like scene files having control, could
> insert default values in their povray.ini, and they could likewise
> carry on as usual.
> 
> Would there be any problems with this arrangement? I'd *really* like
> to keep "ini_option" in the POV-Ray scene file.
> 
> thanks,
> Glen Berry

-- 
Mr. Art

"Often the appearance of reality is more important 
than the reality of the appearance."
Bill DeWitt 2000

Post a reply to this message

In article <wZmeOGBnBBOdVTR7PqR9bMN3e05c@4ax.com> , Glen Berry 
<7no### [at] ezwvcom>  wrote:

> If someone is afraid of some "rogue" scene file having  too much
> control of their computer, why not just make the settings on the
> command line and/or the "povray.ini" file overide the settings made by
> "ini_option." The settings suggested by "ini_option" would only take
> effect if there were no "default" or overiding value set by either the
> command line or the "povray.ini" file.

I think you are contradicting yourself here. One the one hand you say it
eases frequent changes of options, on the other hand you suggest to give it
the lowest possible precedence.

Currently the order is (some elements are optional):

- Enviroment variable (supply alternate name for "povray.ini")
- povray.ini or env.var. name
- Command line
- INI files
- Write INI file
(- ini_option)

You suggest:

- Enviroment variable (supply alternate name for "povray.ini")
(- ini_option)
- povray.ini or env.var. name
- Command line
- INI files
- Write INI file

As you can see, if you specify to write an INI file now it will contain all
options, and the next time you render ini_option settings will be ignored.

But that is not all!  How can this _ever_ work at all?  Don't you at least
need the command line to specify the scene file?  What is about animation,
you would basically have to restart POV-Ray for each frame as you would have
to read all INI files again.

> For those of us that like to specify ini options in the scene file, we
> could simply leave empty spaces in our povray.ini files and carry on
> as usual. Those that didn't like scene files having control, could
> insert default values in their povray.ini, and they could likewise
> carry on as usual.

As said, it simply does not work as you suggest.

> Would there be any problems with this arrangement? I'd *really* like
> to keep "ini_option" in the POV-Ray scene file.

Consistency, among many others. POV-Ray allows the user of the local
POV-Ray, not the person who wrote the file to force the settings.  After all
you can always include an INI file with your scene archive.

So, as there is obviously no problem sending files to others, this leaves
you working with your own scenes.  I can see why you would like to change
settings easily.
Well, lets look at three different platforms and how it works on each with
one file open:

Windows:  Open the scene file, change your scene, save, go to the ini
settings button, change the command line (which is kept between renders) and
render.  Repeat all as often as you like, can change settings without having
to go to editor. You can change the scene instantly.

Mac OS:  Open the scene file, change your scene, save, open render settings,
change settings and render.  Repeat all as often as you like, can change
settings without having to go to editor. You can change the scene instantly.

Unix:  Open the scene file, change your scene, save.  Go to command line
window (or have an editor that can execute a command line), use your own
script or just the previous command lines and edit it, hit return (render).
Repeat all as often as you like, can change settings without having to go to
editor. You can change the scene instantly.


Now, by placing it in the scene file, what do you gain? Lets see:

Windows:  Open the scene file, change your scene, scroll to the ini_option
line, render.  To change settings in scene, edit, save, render.  To change
scene, scroll to last edited position and change scene, (optional: go back
to settings change them) and render.

Mac OS:  Open the scene file, change your scene, scroll to the ini_option
line, render.  To change settings in scene, edit, save, render.  To change
scene, scroll to last edited position and change scene, save, (optional: go
back to settings change them) and render.

Unix:  Open the scene file, change your scene, save scene.  Go to command
line window (or have an editor that can execute a command line), use your
own script or just the previous command lines and edit it, hit return
(render).  To change settings in scene, edit, save, go to command line,
(edit it) and render.

Now, there is also one thing common you make much hard on each platform:
Undo.  A typical editor will only allow you to undo your changes in
sequence, thus you always undo your ini_option settings at first.  In
addition, you each time have to scroll to change settings, also some editors
offer split views. And, did you notice that no usability is gained, to the
contrary, on each platform everything changes from the default behaviour all
programs offer which is a linear model, not the switching/scrolling all the
time.


Additionally, even if you can dismiss all these arguments as user
preference, look at the support problems:  Let someone add ini_option="+rq"
in the file. Now when you get a scene and start to render and it it terribly
slow, people will complain. Not to the author of the scene, but you know to
whom...
And what is about users who don't use command lines/ini files?  All three
platforms above offer powerful graphical user interfaces which do or may
offer comfortable dialogs to set options.  Those users first have to learn
command line settings in order to understand this, increasing slope of the
learning curve even more.  And it breaks user perception of a GUI which
should hide complexity (optional access to the command line is a plus of
course).
Further usability aspects are that it is not possible (technically) to allow
all kinds of settings with the "ini_option". This makes it even more
complicated to use without having to as the command line/ini files are just
fine.
And, as consistency is an issue, it is a valid (also not the strongest)
argument to ask:  Are there other (frequently used) programs which allow you
in command line systems that offer a similar interface?  The only one I can
come up with are compiler with makefiles (= ini files), the command line and
"# pragma " directives (= "ini_option").  However, is a compiler a end-user
program?


       Thorsten


Opinions express are my own and do not represent the POV-Team.

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote...
>
> And, as consistency is an issue, it is a valid (also not the strongest)
> argument to ask:  Are there other (frequently used) programs which allow
you
> in command line systems that offer a similar interface?  The only one I
can
> come up with are compiler with makefiles (= ini files), the command line
and
> "# pragma " directives (= "ini_option").  However, is a compiler a
end-user
> program?

(To start, I must say that I agree with Thorsten that ini_option is not THE
solution to the current problems.  But I also want to say that
problems/limitations do exist, and ini_option has shown itself to be a
reasonable temporary solution.)

One could also ask, "How do other rendering programs handle these settings?"
Are they stored in the main file for the project?  Are they stored in a
separate file?  Honestly, I don't know the answer to this.  I assume that
these settings are stored in a primary project file.  One could view an INI
file as the main project file.  However, many users view the POV file as the
main project file.  Then, they want to specify their settings in their main
project file, which in their eyes is the POV file.

Unfortunately, I feel that the INI file is very inadequate to be a primary
project file.  The syntax is just too limited.  (I won't go into detail
about this in this post, however.)

You gave an example supporting your point using "+QR".  This setting is
actually THE reason that I created ini_option.  In many of my test renders
while I was working on enhancing POV's radiosity features, I was always
opening up the render options dialog box to turn radiosity on and off.

Sometimes, I'd forget to turn it on and waste time rendering a test image
without radiosity.  Other times, I'd forget to turn it off and a different
image that was not designed for radiosity would take forever to render (and
look quite poor).  It was a hastle to keep having to open that dialog box
and change the setting, and (IMHO) it would have been even more of a hastle
to have a separate INI file for each POV file (and have all of those
separate files open at the same time in the GUI).

I wanted it to work like this: if I specified "radiosity{...}" in the POV
file, radiosity would be enabled, and if I did not specify "radiosity{...}",
then radiosity would be disabled.

Anyway, Francios Dispot brought up a good point that INI option allows the
user to modify settings such as the aspect ratio of the image using POV
code.  For example, the POV file could determine the size of an object
(using min_extent and max_extent or trace()) and then use that data to set
the aspect ratio.

However, I do totally agree with you that ini_option has problems with
consistency in the current way POV handles such options.  However, I feel
that there are some shortcomings in the current official design which are at
least temporarily addressed by ini_option, even if that is not the best
solution for the long term.  (Example: I was rendering a MegaPov demo scene
the other day, and I wanted to render it very small just to make sure it
didn't crash my new compile... but the file had ini_option setting the
render size so it ended up rendering much larger than I wanted... which
really annoyed me.)

Specific problems that ini_file addresses:

* enabling/disabling radiosity: Treating it as a render 'quality' setting
just doesn't work.  Why?  Because scenes that are intended to use radiosity
look good with it and not-so-good without it, and scenes not intended to use
radiosity look good without it and bad with it.  Adding "+QR" does not add
to the quality unless the scene was designed with it in mind.  Therefore,
radiosity should be enabled within the POV file as opposed to from an INI
file.  I want it to work like area_lights, reflection, and refraction, all
of which are enabled by the POV file but can be disabled by setting a low
quality setting.

* setting the aspect ratio in the POV file based on objects in the scene:
Sometimes this is useful, but often it is not.

* automatically matching the aspect ratio of the camera with that of the
rendered image:  This is addressed using the new image_height and
image_width variables, and therefore is no longer a problem.

* encapsulating the majority of a POV project within a single file:  I know,
ini_option doesn't even come close to succeeding at this.  But it is a step
in that direction.  Of course, whether or not that is a step in the RIGHT
direction is another question.  Comments?

Those are the only things that I've used it for.  For setting the general
size of the image (as opposed to aspect ratio), I've always used the GUI.

Therefore, once those items are addressed in other ways (and most of them
have already been discussed by the POV-Team), then ini_option will no longer
be necessary.  That is the reason I said it may not always remain.  It will
remain in MegaPov until it is no longer needed.

-Nathan

Post a reply to this message

Nieminen Juha <war### [at] punarastascstutfi> wrote...
> ingo <ing### [at] homenl> wrote:
> : "Note: The ini_option will probably be discontinued in the future."
> : Why is this?
>
>   I don't know the reason, but I can imagine a couple of them:
>
>   - Security.

Not a problem in the current implementation.

>   - The type of rendering (size, antialiasing, etc) should specified
outside
> the scene, not inside.

Why?  Because "that's the way it's always been"?  That by itself is not a
good reason.  (That reason, coupled with "users appreciate backwards
compatibility and consistency", as Thorsten mentioned, is a pretty good
reason, however.)

-Nathan

Post a reply to this message

Nieminen Juha <war### [at] punarastascstutfi> wrote...
> Francois Dispot <woz### [at] club-internetfr> wrote:
> : OTOH being able to determine the size of a picture at render time can be
> : useful for special applications like automatic rendering of ttf fonts
> : samples.
>
>   You don't need ini_option for this.
>

How?  I think he's talking about using min_extent and max_extent so as to
render only what is within the bounding box of the object.

-Nathan

Post a reply to this message

In article <389f1394@news.povray.org> , "Nathan Kopp" <Nat### [at] Koppcom> 
wrote:

> You gave an example supporting your point using "+QR".  This setting is
> actually THE reason that I created ini_option.  In many of my test renders
> while I was working on enhancing POV's radiosity features, I was always
> opening up the render options dialog box to turn radiosity on and off.

I just gave it because it was the only feature I could come up with that
increases render time.
In general regarding radiosity - as you know from previous discussion - I
agree it should be turned on/off different in the future :-)


     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

Nathan Kopp wrote:

> For setting the general size of the image (as opposed to aspect ratio),
> I've always used the GUI.

I have always used the same method for both image size and anti-aliasing
and I am comfortable with it. Quickres.ini serves it's purpose well in
this regard.

> * encapsulating the majority of a POV project within a single file:  I know,
> ini_option doesn't even come close to succeeding at this.  But it is a step
> in that direction.  Of course, whether or not that is a step in the RIGHT
> direction is another question.  Comments?
> 
> Therefore, once those items are addressed in other ways (and most of them
> have already been discussed by the POV-Team), then ini_option will no longer
> be necessary.  That is the reason I said it may not always remain.  It will
> remain in MegaPov until it is no longer needed.
> 
> -Nathan

The four areas that I would value this feature for are (in no particular
order of importance) -

1.) image output format i.e. tga, png, ...

2.) radiosity on/off - options

3.) animation options - clock, Initial_Frame, Final_Frame, Cyclic_Animation...

4.) automatic bounding on/off

  Any other ini options that are available I use so seldom I can live
with adding them to an ini file when needed. The options listed above
however I use frequently enough that it would be nice to have them
available within the scene file I am working on.
  Then again from a Windows only perspective if all of these options
were added as part of the GUI ( a drop down menu ) they too could be
eliminated having no reason for them at all. The only people that
lose in this scenario are those platforms where it might be impossible
to add them because there is no GUI available.


-- 
Ken Tyler -  1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

In article <389F2908.CE8E89AE@pacbell.net> , Ken <tyl### [at] pacbellnet>  
wrote:

> The four areas that I would value this feature for are (in no particular
> order of importance) -
>
> 1.) image output format i.e. tga, png, ...

Hmm, "sys"?  ;-)

> 2.) radiosity on/off - options

Agreed.

> 3.) animation options - clock, Initial_Frame, Final_Frame, Cyclic_Animation...

Interesting, I never thought about that but it would make sense once the
need for re-parsing for animations is eliminated. It would however break the
QT movie output on Macs, but I could surely find a solution.

> 4.) automatic bounding on/off

Maybe a better bounding system would also do the job?


     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

Ken <tyl### [at] pacbellnet> wrote...
>
> 2.) radiosity on/off - options

As Thorsten hinted at, this is being addressed by the POV-Team and an
alternative solution (which does not require ini_option) has been
tentatively agreed upon.

> 3.) animation options - clock, Initial_Frame, Final_Frame,
Cyclic_Animation...

You are not able to use ini_option to set these options, since they must be
set before the POV file is parsed.

> 4.) automatic bounding on/off

This might be a nice option to specify in the POV file, since POV messes up
the automatic bounding in some scenes and not others, and it would be nice
to turn it off for those scene where it doesn't work without messing with
INI files where you might forget to turn it back on for other scenes.

-Nathan

Post a reply to this message

Thorsten Froehlich wrote:

> > 1.) image output format i.e. tga, png, ...
> 
> Hmm, "sys"?  ;-)

Well it is a platform independant option anyway isn't it ?
 
> > 3.) animation options - clock, Initial_Frame, Final_Frame, Cyclic_Animation...
> 
> Interesting, I never thought about that but it would make sense once the
> need for re-parsing for animations is eliminated. It would however break the
> QT movie output on Macs, but I could surely find a solution.

I think those that do a lot of animation work would really appreciate this
one. As far as the QT problem Thorsten is wise and all knowing so finding
a solution should be no problem :)

> > 4.) automatic bounding on/off
> 
> Maybe a better bounding system would also do the job?

This of course would be preferable. I never know for sure when manual
bounding will help out and usually only through trial and error do I
find out if it helps the render time. Still there are some games you
can play with manual bounding for special effects that it would be
nice to be able to disable it when you want to.

-- 
Ken Tyler -  1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

Nathan Kopp wrote:
> 
> >   - The type of rendering (size, antialiasing, etc) should specified
> outside
> > the scene, not inside.
> 
> Why?  Because "that's the way it's always been"?  That by itself is not a
> good reason.  (That reason, coupled with "users appreciate backwards
> compatibility and consistency", as Thorsten mentioned, is a pretty good
> reason, however.)
> 
> -Nathan

I've always considered it obvious that the scene file describes the
_scene_ not the image.

Some kind of Allow_Scene_Ini_Options option strikes me as a good idea.

PoD.

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote...
>
> In general regarding radiosity - as you know from previous discussion - I
> agree it should be turned on/off different in the future :-)

Yes, I remember that discussion.  I had forgotten that I acutally did get
around to implementing that in MegaPov already.  MegaPov users please see
section 10.2.10 of the MegaPov documentation.

-Nathan

Post a reply to this message

On Mon, 07 Feb 2000 12:20:24 -0800, Ken <tyl### [at] pacbellnet> wrote:

>
>
>Nathan Kopp wrote:
>
>> For setting the general size of the image (as opposed to aspect ratio),
>> I've always used the GUI.
>
>I have always used the same method for both image size and anti-aliasing
>and I am comfortable with it. Quickres.ini serves it's purpose well in
>this regard.
>

As long as one doesn't have files created with a multitude of
different aspect ratios, then "quickres.ini" does work pretty well,
for windows users at least. I happen to have files that I have created
for several different aspect ratios. 

I can't simply render one of my files without having to find the
camera statement in each one, and determine the aspect ratio for the
image. Then I pick an appropriate height and width to enter into the
GUI by hand, because all too often, that particular aspect ratio isn't
supported by "quickres." Yes, I have a modified version of quickres
that includes other aspect ratios, but it is a pain to create
*several* new entries in this file for each aspect ratio that I want
to support. The resulting file also becomes awkward to scroll through,
because of the sheer number of presets I have incorporated.

It is much easier to simply write the height and width into the scene
file, near the top of the file, and then I never render it at the
wrong aspect ratio. If I want to change the size, I simply edit the
scene file, which is not awkward, since the size is specified near the
top of the file, easy to find.

As for aspect ratio, perhaps it would be possible to seperate it from
the actual image size in some way. Currently it is only possible to
set it indirectly. What if we could specify the scene Height and
Aspect Ratio, instead of Height and Width? The Aspect Ratio would be
set in the scene file, and you could set the Height from the command
line or "povray.ini." That way, no matter what size you rendered a
scene file at, it would have the proper aspect ratio. There would no
longer be the need for checking the camera statement in each scene
file before rendering, to determine the proper aspect ratio to
indirectly set via the Height and Width settings. Does anyone like
this idea?

later,
Glen Berry

Post a reply to this message

On Mon, 7 Feb 2000 13:49:45 -0500, "Nathan Kopp" <Nat### [at] Koppcom>
wrote:

>Why?  Because "that's the way it's always been"?  That by itself is not a
>good reason.  (That reason, coupled with "users appreciate backwards
>compatibility and consistency", as Thorsten mentioned, is a pretty good
>reason, however.)
>

Speaking in general, the "backwards compatibility" flag is waved by
*someone* almost every time a change is suggested. I say if a
particular  change is for the better, then screw backwards
compatibility. If I have to change syntax on one of my older scene
files to accomodate a new version of POV, then so be it. I won't be
crying about it. I'll be too busy appreciating the new features or
improvements. I'd hope that most people have a similiar opinion. 

Please note that this post isn't concerning the ini_option issue. I
just want to express this opinion openly in regards to *any* change
that is being considered by the POV-Team, or any of the programmers
making custom patches. Please, don't ever be afraid to try something
new.

thanks,
Glen Berry

Post a reply to this message

I like it. Only I would set Width and Height and let
the program set the aspect. It would be overridden only
if you set the camera{ right } option.

Glen Berry wrote:
> 
> On Mon, 07 Feb 2000 12:20:24 -0800, Ken <tyl### [at] pacbellnet> wrote:
> What if we could specify the scene Height and
> Aspect Ratio, instead of Height and Width? The Aspect Ratio would be
> set in the scene file, and you could set the Height from the command
> line or "povray.ini." That way, no matter what size you rendered a
> scene file at, it would have the proper aspect ratio. There would no
> longer be the need for checking the camera statement in each scene
> file before rendering, to determine the proper aspect ratio to
> indirectly set via the Height and Width settings. Does anyone like
> this idea?
> 
> later,
> Glen Berry

-- 
Mr. Art

"Often the appearance of reality is more important 
than the reality of the appearance."
Bill DeWitt 2000

Post a reply to this message

On Tue, 08 Feb 2000 09:34:42 +1030, PoD <pod### [at] merlinnetau> wrote:

>I've always considered it obvious that the scene file describes the
>_scene_ not the image.

Now, that statement could get rather philosophical!  :)

I wonder if, since it's strictly a description of the scene as you
say, should we remove the camera from the scene file? (Unless of
course, it actually appears in the scene as a reflected object or
something.)     <just kidding with you>

>Some kind of Allow_Scene_Ini_Options option strikes me as a good idea.

That would make me happy. 

If the POV-Team wants, it could be an option that is disabled by
default. Then only those users that really want it would be using it.
That would greatly reduce the potential support problems - if that is
the concern for them with this issue.

later,
Glen Berry

Post a reply to this message

On Mon, 07 Feb 2000 20:17:59 -0900, "mr.art" <mr.### [at] gcinet> wrote:

>I like it. Only I would set Width and Height and let
>the program set the aspect. It would be overridden only
>if you set the camera{ right } option.
>
You have me a bit confused here. If you are setting the Width and
Height of the image, then you have also set the aspect ratio of the
image as well. The program can't independently set the aspect ratio,
and also allow you to set both Height and Width at the same time. 

Perhaps you could explain this for me?

thanks,
Glen Berry

Post a reply to this message

Set width to 800, height to 600. Then set right to anything other
than 4/3*x and watch what happens. The image is stretched oddly.
So set the image to 800x450, leave right alone. The image is
stretched oddly. I would like to see povray try to keep the image
of a sphere round unless you tell it to do otherwise.

Glen Berry wrote:
> 
> On Mon, 07 Feb 2000 20:17:59 -0900, "mr.art" <mr.### [at] gcinet> wrote:
> 
> >I like it. Only I would set Width and Height and let
> >the program set the aspect. It would be overridden only
> >if you set the camera{ right } option.
> >
> You have me a bit confused here. If you are setting the Width and
> Height of the image, then you have also set the aspect ratio of the
> image as well. The program can't independently set the aspect ratio,
> and also allow you to set both Height and Width at the same time.
> 
> Perhaps you could explain this for me?
> 
> thanks,
> Glen Berry

-- 
Mr. Art

"Often the appearance of reality is more important 
than the reality of the appearance."
Bill DeWitt 2000

Post a reply to this message

On Mon, 07 Feb 2000 21:06:03 -0900, "mr.art" <mr.### [at] gcinet> wrote:

>Set width to 800, height to 600. Then set right to anything other
>than 4/3*x and watch what happens. The image is stretched oddly.
>So set the image to 800x450, leave right alone. The image is
>stretched oddly. I would like to see povray try to keep the image
>of a sphere round unless you tell it to do otherwise.
>

In that case, my suggestion of specifying the aspect ratio in the
scene file, and *either*  Width or Height, but *not both* on the
command line (or povray.ini) would work. The image aspect ratio could
be set with the camera{right} statement. Then we only need to specify
*one* of the image dimensions on the command line. POV would calculate
the other dimension.

I'm not forgetting that some systems might not employ square pixels.
I'm also aware of the idea that some people might want to create
images that are "compressed" in one dimension. For those situations, I
propose that an option be created for the povray.ini file that
specifies the *pixel* aspect ratio. This could also be used on the
command line.

There is a definite practical advantage of having seperate variables
assigned for the aspect ratio of the output image, and a second
variable associated with the aspect ratio of an individual pixel. 

Yes, all of this can be achieved currently, but it is awkward to work
with multiple, image aspect ratios with the current system.

later,
Glen Berry

Post a reply to this message

Nathan Kopp <Nat### [at] koppcom> wrote:
:> : OTOH being able to determine the size of a picture at render time can be
:> : useful for special applications like automatic rendering of ttf fonts
:> : samples.
:>
:>   You don't need ini_option for this.

: How?  I think he's talking about using min_extent and max_extent so as to
: render only what is within the bounding box of the object.

  Sorry, I thought that "determine" means "get information about".

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Nathan Kopp <Nat### [at] koppcom> wrote:
:>   - The type of rendering (size, antialiasing, etc) should specified
: outside
:> the scene, not inside.

: Why?

  I said why in the part you didn't quote.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Glen Berry wrote:
> 
> On Mon, 07 Feb 2000 21:06:03 -0900, "mr.art" <mr.### [at] gcinet> wrote:
> 
> >Set width to 800, height to 600. Then set right to anything other
> >than 4/3*x and watch what happens. The image is stretched oddly.
> >So set the image to 800x450, leave right alone. The image is
> >stretched oddly. I would like to see povray try to keep the image
> >of a sphere round unless you tell it to do otherwise.
> >
> 
> In that case, my suggestion of specifying the aspect ratio in the
> scene file, and *either*  Width or Height, but *not both* on the
> command line (or povray.ini) would work. The image aspect ratio could
> be set with the camera{right} statement. Then we only need to specify
> *one* of the image dimensions on the command line. POV would calculate
> the other dimension.
> 
> I'm not forgetting that some systems might not employ square pixels.
> I'm also aware of the idea that some people might want to create
> images that are "compressed" in one dimension. For those situations, I
> propose that an option be created for the povray.ini file that
> specifies the *pixel* aspect ratio. This could also be used on the
> command line.
> 
> There is a definite practical advantage of having seperate variables
> assigned for the aspect ratio of the output image, and a second
> variable associated with the aspect ratio of an individual pixel.
> 
> Yes, all of this can be achieved currently, but it is awkward to work
> with multiple, image aspect ratios with the current system.
> 
> later,
> Glen Berry

A pixel aspect ratio would be mandatory unless square pixels are
default.
If I said width=320, ar=4/3, do I want 320x240 or 320x200 VGA mode?

PoD.

Post a reply to this message

On Wed, 09 Feb 2000 09:25:44 +1030, PoD <pod### [at] merlinnetau> wrote:

>A pixel aspect ratio would be mandatory unless square pixels are
>default.
>If I said width=320, ar=4/3, do I want 320x240 or 320x200 VGA mode?
>

Yes, like I said, a pixel aspect ratio should be set seperately. So
you would have something like this:

  Scene File:
     image_aspect_ratio=4/3

  ini File or Command Line:
    Width = 320
    Pixel_Aspect_Ratio = 1

From these three variables, POV-Ray could determine that a person
wanted a 320x240 output image to be displayed on a system that used
square pixels.

Post a reply to this message