> Yes, that would work...as long as you put everything at the start of the
> scene. Which isn't always possible, with includes and macros for example.

Here is a model which might be closer to a solution:

One limitation of POV script is that it's not possible to
pass values into it without editing the source.  There is
no C-style main(int argc,char *argv[]) and no way to
read environment variables.  In this sense, a pov scene
is a void main(void) except that you can control the
clock timer variable.

I would suggest a mechanism where values can be passed
at the command line, or alternatively, edited at an 
interactive prompt in text or GUI form.  You support
some sort of block declaration at the start of the POV
file that _allows_ but doesn't _require_ passing from 
command line or a text or GUI editor.  You only support
it if it's the first thing in the file, and you take
notice of the first block only.  The defaults are used
for subsequent blocks.

If you try to pass something on the command line that
isn't in the first block, an error results.  If you
want to edit the parameters manually, you must enable
it via command line or in the GUI.

An example:

interface 
{
	#declare X = 0;
	#declare Y = 1;
	#decalre Z = "hello";
}

c:\> povray +w320 +h240 +ifile.pov +DX=5 +DY=0 +DZ=bye

That's the idea anyway - it solves the parser stalling
problem, and it simplifies the prompting, because no
timeout is necessary.

And, I think it's not so ambitous that we'd be 
waiting around for POV 4.0 to implement it.

--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.

Post a reply to this message

Nigel Stewart wrote:

> If you try to pass something on the command line that
> isn't in the first block, an error results.  If you
> want to edit the parameters manually, you must enable
> it via command line or in the GUI.

Speaking of errors something else that will have to be address is
error handling of erroneous input. If the user_prompt is looking for
a specific input and a wrong value is entered there needs to be
some form of error trapping to get the right value from the user.

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

> Speaking of errors something else that will have to be address is
> error handling of erroneous input. If the user_prompt is looking for
> a specific input and a wrong value is entered there needs to be
> some form of error trapping to get the right value from the user.

	That's a very good point, and I think the best way to
	handle it is with some POV script code to do the range
	or consistency checking.  Ultimately - leave it up to
	the script to handle it.

	But, if you want a model that prompts you again
	with a message that the input was out of range,
	then you're back to the problems of the original
	proposal.

	I think that without this "second chance" it's
	still a useful mechanism, and worth considering
	seriously.

--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.

Post a reply to this message

In article <GIHOOHWP57GVgbOx81s8aTSybt3d@4ax.com>, Glen Berry
> <7no### [at] ezwvcom> wrote:
> 
> > I can't imagine how it would possibly take anything approaching 45
> > minutes to scan for the appearance of a few interactive keywords,
> > requiring user data input,  in a POV scene file. If some are found,
> > the values would be entered at that time, before the "real" parsing
> > would begin. There should be no such thing as sitting in front of your
> > monitor for 45 minutes waiting to enter data into a scene that is
> > parsing.

#declare L=rand(Seed)*10;
#declare A = array[L];
#declare I=0; #while(I<L)
 A[I] = user_input();
 #declare I=I+1; #end

Yes, I've also read the bit about time-outs and default values.
This makes what would be fairly simple to do portably more problematic.
You now need a portable way to wait n seconds for user input, else
continue running.

The command line idea has the most promise, IMHO. Except then the
command line args need to match the variables in the script.

The most portable way would be to not change anything. Include a .inc
file which defines your variables, put a note in your script and maybe a
#debug to remind users to set the values.

PoD.

Post a reply to this message

In article <38CF8393.4C9C700B@nigels.com>, nig### [at] eisanetau wrote:

> 	The "base level interface" of POV has always been a command
> 	line with standard input and standard output available.
> 	I'm sure the Windows guys can supply you with a dialog box,
> 	and similarly for other non-text-terminal style incarnations
> 	could manage this very basic requirement.

You might be surprised to learn that the Mac version of POV does not 
have an accessible command line. None. And the only text input is the 
scene file and optionally an .ini file(usually, those preferences are 
stored in the actual scene file, in the resource fork).
Maybe this will change in 3.5, though. And you theoretically could 
compile a console version of POV...


> > it would just be too difficult to implement in POV-Script 
> 
> 	<disbelief> Huh? </disbelief>

<frusteration>I was referring to the problem of pre-parsing the scene to 
keep from having long delays before input requests.</frusteration>


> > and impossible to implement in a cross-platform manner
> 
> 	<amusement> Refer to ANSI C Standard: scanf(...) </amusement>

<incomprehension>Er, how would this help in putting up a dialog box and 
getting user input from it?</incomprehension>


> > And then you have to write the dialog code for Mac and Windows
> 	
> 	No, you provide a hook with sensible default behaviour.
> 	(if there is no function pointer, don't prompt.  Simple huh?)

There are output functions for warnings and errors, but I don't know if 
there are input functions(there actually might be, maybe they just have 
never been used). Adding them wouldn't be difficult, but it would 
probably be a better idea to put everything into one standardized 
interface during the conversion to C++. If you can add them in now, go 
ahead!


> > This would be a nice feature, and probably something to think about for
> > POV 4.0
> 
> 	<sarcasm>
> 	Ooooh.... That's an ambitous goal - a C++ port in order to
> 	support a prompt.  Good thinking.  Perhaps C++ would also
> 	help with "general solutions" that don't exist.
> 	</sarcasm>

<exasperation>Did I say this was the only reason to port to C++? No.
I meant this was a good thing to think about and plan for in the design 
of 4.0.</exasperation>


> > but in the current state of POV is just not very
> > plausible. Another good addition to the wish-list, though.
> 
> 	Wish list?  I just about tempted to hack this into POV
> 	and post a binary just to prove you wrong. Let's see,
> 	one reserved word, two numerical parameters, a bit
> 	of cut-paste-and-edit.  Sounds more than plausible.

Go ahead...don't forget to work out the problem of pre-parsing the scene 
while you are at it. :-)

Actually, for now, a simple version of this feature which doesn't do 
pre-parsing would probably be enough, as long as people design their 
code carefully and include files don't require them(maybe a way to turn 
this feature off for sections of code would be a good idea? 
#user_prompts on/off in addition to the prompt_user() function?). The 
function hook for the user prompt could also be hacked in. The 
pre-parsing stuff could be added later, maybe in 4.0.

Or maybe the suggestion of having everything be put in a special block, 
like global_settings, so everything has to be specified at the beginning 
of the scene. This seems too rigid, though.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

> >       <disbelief> Huh? </disbelief>
> <frusteration>I was referring to the problem of pre-parsing the scene to
> keep from having long delays before input requests.</frusteration>

	<sympathethic> Fair Enough </sympathetic>

> > > and impossible to implement in a cross-platform manner
> >       <amusement> Refer to ANSI C Standard: scanf(...) </amusement>
> 
> <incomprehension>Er, how would this help in putting up a dialog box and
> getting user input from it?</incomprehension>

	<rationalisation> In this sense MAC is not even ANSI standard,
        so you are always up for GUI programming, no matter what you do.
	</rationalisation>

> If you can add them in now, go ahead!

	I think the "interface block" concept is the most promising
	formulation that we have so far.  It's something like
	the main(..) function in C, you're only allowed to have one.

> This seems too rigid, though.

	Perhaps a bit rigid, but still very useful.  And it's not
	an unreasonable solution to the problem.  It certainly
	beats editing POV script by hand.

--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.

Post a reply to this message

In article <38D02C53.7176F1A8@nigels.com>, nig### [at] eisanetau wrote:

> 	I think the "interface block" concept is the most promising
> 	formulation that we have so far.  It's something like
> 	the main(..) function in C, you're only allowed to have one.
> 
> > This seems too rigid, though.
> 
> 	Perhaps a bit rigid, but still very useful.  And it's not
> 	an unreasonable solution to the problem.  It certainly
> 	beats editing POV script by hand.

But if there can only be one in each scene, the only logical place would 
be the main scene file. So you couldn't have the scene file request 
values from the user...and you would still have to remember the variable 
names.
I rather like the prompt_user() function idea, you would just have to 
use it sparingly, make sure to put it in the right places(not in long 
loops and not after long calculations, for example), and just generally 
be careful with it, at least until support could be extended to support 
pre-parsing operations.

If you really have a problem with remembering variable names and don't 
want to use comments as a reminder, maybe you could put a list of 
#declare's(with default values) of the variables in a separate include 
file, make copies of that, and design the include file so it only takes 
one variable-the name of the include file you want it to use for input. 
You could just edit the values in a copy of the file, no need to 
remember any names other than the one file name variable(and the name of 
the main include file, but you would have to remember that one anyway. 
:-) ).

// parameter file
...miscellaneous variable declarations...
...just make a copy of this file and modify as needed...
// end parameter file

// main include file
#ifndef(paramFile)
    #declare paramFile = "defaultParams.inc"
#end

#include paramFile

...
// end main include file


// scene file
...you only have to remember this variable...
#declare paramFile = "myParams.inc"
#include "main include file.inc"
...
// end scene file


I hope that made some sense.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

In article <chrishuff_99-EFDC80.20133115032000@news.povray.org>, Chris 
Huff <chr### [at] yahoocom> wrote:

> In article <38D02C53.7176F1A8@nigels.com>, nig### [at] eisanetau wrote:
> 
> > 	I think the "interface block" concept is the most promising
> > 	formulation that we have so far.  It's something like
> > 	the main(..) function in C, you're only allowed to have one.
> > 
> > > This seems too rigid, though.
> > 
> > 	Perhaps a bit rigid, but still very useful.  And it's not
> > 	an unreasonable solution to the problem.  It certainly
> > 	beats editing POV script by hand.
> 
> But if there can only be one in each scene, the only logical place would 
> be the main scene file. So you couldn't have the scene file request 
> values from the user...

Er, I meant you can't have the include files request values. Oops! :-)

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

> > >     I think the "interface block" concept is the most promising
> > >     formulation that we have so far.  It's something like
> > >     the main(..) function in C, you're only allowed to have one.

> Er, I meant you can't have the include files request values. Oops! :-)

	That's right - but this is actually a feature - it puts
	one module in control of user interaction.  

	You simply design the script to pass values from the
	interface block to the included files, or to the
	macros.  Something like:

interface
{
	#declare ShowBackground = 1;
	#declare ShowLandscape = 1;
	#declare NumberOfTrees = 100;
}

#if (ShowBackground)
  #include "background.inc"
#end

#if (ShowLandscape)
  #include "landscape.inc"
#end

// The Trees include uses TREES_NUMBER to
// control the number of generated trees.

#declare TREES_NUMBER = NumberOfTrees;
#include "trees.inc"


--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.

Post a reply to this message

Chris Huff wrote:

> > But if there can only be one in each scene, the only logical place would
> > be the main scene file. So you couldn't have the scene file request
> > values from the user...

Not necessarily. The block could go into the .inc file itself. The .inc
file then could be included at the beginning of the file. The only real
situation that I can see where you may have to wait around for more
user_prompts is if you use the include file to create multiple unique
objects from the same include file. For example the include file is a
tree generator and you want 20 unique trees in your scene it would
require you to call the include file more than one time in the main
scene file. It would of course make sense that those using this feature
decide when it would be useful to utilize this feature and to know
when to use other methods of letting the user preset variables such as
the current system allows.

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