From the megaDoc:



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:


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


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

-- 

      __  __ __  __  _
|  | /  \  /  / |_  /  |/
\/\/ \__/ /_ /_ |__ \_ |\

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