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

> Perhaps the parser could scan for such interactive features first, and
> let the user know that they need to watch the screen to add input to
> the scene data. If no interactive features were found in the scene
> files, then the parser could even issue a statement to that effect,
> and proceed to render the scene while you went out for the weekend.

There is still the problem of having to wait for the dialog/prompt to 
pop up while the scene is parsing. I have had scenes that took 45 
minutes to parse.


> It should also be possible to "remember" the values entered during the
> last rendering of an interactive scene file, and use them for
> "default" values when queried by the current interactive rendering.
> Let's say you have ten seconds to change the default value, or the
> scene continues parsing with the default value. Hitting the "return"
> key would simply accept the default value as-is, and avoid the ten
> second delay. In order to store the previous query values, POV's
> text-file output capabilities can be put to use in a method similar to
> Nathan's use of an external file for storing photon or radiosity data
> for subsequent renders.

This is getting too interface-dependant. I would rather not have 
language features depend on the interfaces of different platforms.
And what about automatic rendering? If POV is being controlled through 
something like a web page, this kind of feature would have to be removed 
or heavily modified.

It is simple enough to make an include file with the variables you want 
to use so you don't have to remember the names, or you can put them in 
the main file and just use comments well. And this doesn't have the 
complications of a user prompt.

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

Post a reply to this message

Glen Berry wrote:

> It isn't to me, but it is for some people. I would rather see old
> versions of POV used to handle old POV code, than trying to make a new
> version of POV bend over backwards and parse legacy code. It usually
> isn't that hard to update a POV scene to fit a revised syntax. With
> the exception of halos, the feature set only seems to grow, never
> shrink. Even in the case of halos, there are work-arounds.

Hmm. Actually there are people with a large amounts of legacy code and
who are very thankful for backward compatibility ! I can work fast on
very complex scenes today because I can re-use code written 4 years ago
with little changes, apart the occasional missing semi-colon. And I'm not
talking about code that would only take 10-20 minutes of rewriting (this
is the time it may take already to track missing semi-colons).
I do update old code but, believe me, a minimal backward compatibility
is heaven-sent.

Also, I think that one of the big strengthes of POV is that is has been very
stable over the years, possibly at the expense of new stuff coming in.
POV users are basically hobbyists : unlike users working in a professional
environment (who have to keep up with every new thing because the market
demands it) they use it at their own pace, and on their spare time.
We often rely on "old stuff" to have fun, from utilities to macros, include files

or even translated manuals (for the non-English speaking people).
This legacy may be seen as a burden (it certainly is), but it is also one
of the things that keeps POV alive, because it has allowed people to become
experienced and thus make better scenes and share knowledge with new users.


G.

Post a reply to this message

On Tue, 14 Mar 2000 07:15:06 -0500, Chris Huff
<chr### [at] yahoocom> wrote:

>In article <9=XNONfHim9haARAc396blnM8yDn@4ax.com>, Glen Berry 
><7no### [at] ezwvcom> wrote:
>
>> Perhaps the parser could scan for such interactive features first, and
>> let the user know that they need to watch the screen to add input to
>> the scene data. If no interactive features were found in the scene
>> files, then the parser could even issue a statement to that effect,
>> and proceed to render the scene while you went out for the weekend.
>
>There is still the problem of having to wait for the dialog/prompt to 
>pop up while the scene is parsing. I have had scenes that took 45 
>minutes to parse.

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.

>> It should also be possible to "remember" the values entered during the
>> last rendering of an interactive scene file, and use them for
>> "default" values when queried by the current interactive rendering.
>> Let's say you have ten seconds to change the default value, or the
>> scene continues parsing with the default value. Hitting the "return"
>> key would simply accept the default value as-is, and avoid the ten
>> second delay. In order to store the previous query values, POV's
>> text-file output capabilities can be put to use in a method similar to
>> Nathan's use of an external file for storing photon or radiosity data
>> for subsequent renders.
>
>This is getting too interface-dependant. I would rather not have 
>language features depend on the interfaces of different platforms.

Are you telling me that ASCII text file reading and writing is a
highly platform-dependent operation? What about asking an end user to
interactively type a variable in response to an ASCII screen prompt,
are you saying that is also highly platform-dependent? It just so
happens that these operations are found in every basic C/C++ book I
have seen. I always thought they were considered portable.

>And what about automatic rendering? If POV is being controlled through 
>something like a web page, this kind of feature would have to be removed 
>or heavily modified.

Just because a feature might not be useful to you for every scene you
write, doesn't mean the feature shouldn't exist. Do you currently use
every keyword in POV for each scene you create? I think not.

If you have an objection to user-interactive pre-parsing, no one will
make you use it. At this point, I'm wondering if there is *any*
feature-set change I could suggest for POV-Ray and get a favorable
response from you.

>It is simple enough to make an include file with the variables you want 
>to use so you don't have to remember the names, or you can put them in 
>the main file and just use comments well. And this doesn't have the 
>complications of a user prompt.

"...complications of a user prompt"?

Some would say that a user prompt would greatly simplify some things.
One wouldn't have to remember all the names of all the variables in a
scene file that frequently needed changing. The script would prompt
you for values as it needed them. One person could write an
interactive include file and another person could run it without ever
having to look inside the source code to find all the variables that
need to be changed to suit their particular needs. There would be no
more searching through convoluted code, possibly scattered through
several include files.

You seem to have the mind set that in the future all scripts would be
interactive and you wouldn't be able to overide that interactivity. No
one is proposing a scenario like that. If my earlier suggestion for a
default value that is used after time-out period doesn't suit you, it
would also be possible for POV to simply ask if you wanted to
pre-parse the scene in interactive mode, or simply use the last
user-entered values. If no user-entered values existed, default values
could be written into the script. This would be a global rejection of
user-input as compared to the earlier example of line-by-line
bypassing of prompts. Furthermore, both the global and the
line-by-line rejection options could be incorporated into POV-Ray for
the most flexibility.

Later,
Glen Berry

Post a reply to this message

On Tue, 14 Mar 2000 14:39:04 +0100, Gilles Tran <tra### [at] inapginrafr>
wrote:

>Hmm. Actually there are people with a large amounts of legacy code and
>who are very thankful for backward compatibility ! I can work fast on
>very complex scenes today because I can re-use code written 4 years ago
>with little changes, apart the occasional missing semi-colon. And I'm not
>talking about code that would only take 10-20 minutes of rewriting (this
>is the time it may take already to track missing semi-colons).
>I do update old code but, believe me, a minimal backward compatibility
>is heaven-sent.

I can't deny that many people do like a certain level of
backwards-compatibiliy. It might surpise some people to know that *I*
even appreciate a *little* stability. For example, I wouldn't want POV
mutating into something totally incompatible with its previous
incarnation every other week.   :)

It just seems to me that there are people that take a negative
knee-jerk reaction to a proposed changed in POV, and wave the
backwards compatibility flag without giving it much thought. They are
often very vocal and dominating in their quest to crush a new idea.
Often times, they don't understand the new idea they are fighting
against. This can be dangerous.

My recent posts expousing my personal acceptance of breaking backwards
compatibility, to gain advanced features or improve quality is meant
to offer an opposing voice to some of these people. It seemed that few
people were speaking up in opposition, and I felt someone should take
the other side. It's hard to make an enlightened decision until both
sides of an argument are properly presented.

I'm sure that a certain amount of backwards compatibility will always
exist in POV. I'm sure that many people will be comforted by that
notion. My personal situation and feelings will not be applicable to
everyone, but expressing them might give the POV coders a better
understanding of the diversity of their user base.

Later,
Glen Berry

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.

Some of them would not be encountered at first, and some of them would 
be used in calculations already partly done. And you couldn't simply 
scan the file for them and substitute them with values as a 
preprocessing step without following the conditionals and loops, which 
would mean there would be delays(although shorter than if full parsing 
was being done) and it would be significantly harder to implement. You 
might want to just rely on people writing friendly code that requests 
all variables at once before anything is done, but you still can't 
guarantee that your code will be reached early in the parsing.



> >This is getting too interface-dependant. I would rather not have 
> >language features depend on the interfaces of different platforms.
> 
> Are you telling me that ASCII text file reading and writing is a
> highly platform-dependent operation? What about asking an end user to
> interactively type a variable in response to an ASCII screen prompt,
> are you saying that is also highly platform-dependent? It just so
> happens that these operations are found in every basic C/C++ book I
> have seen. I always thought they were considered portable.

No, I am saying ASCII is platform independant, but a user prompt feature 
would be very interface-dependant. On Mac and Windows(and a few Linux 
versions), it might be a dialog with a text field(which might do direct 
text replacement, with what you input being directly entered into the 
parser). On other systems, it would be a command-line prompt, or an 
automatically generated web page with text boxes for the entered text. 
Although it would be possible for each of these, there would not be a 
portable way of doing it.


> >And what about automatic rendering? If POV is being controlled through 
> >something like a web page, this kind of feature would have to be removed 
> >or heavily modified.
> 
> Just because a feature might not be useful to you for every scene you
> write, doesn't mean the feature shouldn't exist. Do you currently use
> every keyword in POV for each scene you create? I think not.
> 
> If you have an objection to user-interactive pre-parsing, no one will
> make you use it. At this point, I'm wondering if there is *any*
> feature-set change I could suggest for POV-Ray and get a favorable
> response from you.

You haven't seen my suggestions in the past, have you? :-)
I support adding the #for() loop, I would like to see a #set command to 
change variables instead of making new ones, I wrote patches for several 
patterns(solid, blob, blob pigment, proximity, object), I wrote the 
vtransform(), eval_pigment(), eval_pattern(), and noise3d() function 
patches.(NOT the noise3d used in isosurfaces, my patch allows that 
function to be used outside isosurface functions)
I also wrote a kind of z-buffer patch, and a blurred transparence patch.
I have also suggested completely changing the language, starting over 
from scratch to create a language which is easier to learn and use, more 
flexible, and more consistant(although it certainly wasn't a new idea). 
The problems with that idea have made me start work on C-SDL(see my 
posts in .off-topic).
I actually don't have any objection to the idea of interactive scene 
files, I just don't see how they could be done well in POV-Script and in 
POV-Ray.


> >It is simple enough to make an include file with the variables you want 
> >to use so you don't have to remember the names, or you can put them in 
> >the main file and just use comments well. And this doesn't have the 
> >complications of a user prompt.
> 
> "...complications of a user prompt"?
> 
> Some would say that a user prompt would greatly simplify some things.
> One wouldn't have to remember all the names of all the variables in a
> scene file that frequently needed changing. The script would prompt
> you for values as it needed them. One person could write an
> interactive include file and another person could run it without ever
> having to look inside the source code to find all the variables that
> need to be changed to suit their particular needs. There would be no
> more searching through convoluted code, possibly scattered through
> several include files.

This could be done now by using comments to remind you of the variable 
names or by having the variables be declared in a separate file which 
you edit. Not perfect, but quite useable and they exist now.


> You seem to have the mind set that in the future all scripts would be
> interactive and you wouldn't be able to overide that interactivity. No
> one is proposing a scenario like that.

I certainly didn't mean to sound like that. Like I said, I don't have 
any problem with the idea of an interactive script, it would just be too 
difficult to implement in POV-Script and impossible to implement in a 
cross-platform manner(with the current state of POV-Ray, anyway).


> If my earlier suggestion for a default value that is used after 
> time-out period doesn't suit you, it would also be possible for POV 
> to simply ask if you wanted to pre-parse the scene in interactive 
> mode, or simply use the last user-entered values. If no user-entered 
> values existed, default values could be written into the script. This 
> would be a global rejection of user-input as compared to the earlier 
> example of line-by-line bypassing of prompts. Furthermore, both the 
> global and the line-by-line rejection options could be incorporated 
> into POV-Ray for the most flexibility.

The function could be something like this:
user_prompt("message string", "default parameter string")
Things like expiration time(and auto-entering of last-used values) would 
be set by user preferences(the .ini file for most platforms), and the 
entered string would be directly copied into the file(not in the 
original, of course. In the parser.). I don't think there is a problem 
with the idea of a time delay(as long as you can turn it off and adjust 
it's length), just problems with it's implementation.

And then you have to write the dialog code for Mac and Windows, and 
dialog/command line code for DOS and Linux, and anyone doing a port 
would have to modify that portion of the core code(which is supposed to 
be platform independant). The code for one platform could not be used 
for the others. You could just have it always use the defaults if the 
platform doesn't have the user prompt implemented, but I don't think 
that is a good general solution.

And with the modifications that would have to be made to the parser, 
this would not be a small feature to add, it is much more than just a 
little function or block of code somewhere.

This would be a nice feature, and probably something to think about for 
POV 4.0(which is planned to be a rewrite in C++. It might allow the 
modifications for the different platforms to be made more easily, and a 
pre-processing stage could be added during the parser 
rewrite/conversion), but in the current state of POV is just not very 
plausible. Another good addition to the wish-list, though.

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

Post a reply to this message

Chris Huff wrote:

> The function could be something like this:
> user_prompt("message string", "default parameter string")

I was thinking along the same lines ( as far as syntax ) but wonder
if it would be as difficult as you make it sound to pass these user
submitted values to a function. For example what if you simply declared
the user_prompt command as one of your variables -

#declare Var_1 = user_prompt("message string", "default parameter string")

#declare A = 0;
 #while ( A < Var_1 }
  object.....

etc.

In principal it would act as any pre-declared value and is held in
memory before the loop structure is encountered. As long as the
person writing the scene code that utilizes this places the user
prompts before anything else in the scene then you will only encounter
the user prompt during the first few seconds of parsing activity.

-- 
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 <38CEB739.73D6F151@pacbell.net>, lin### [at] povrayorg 
wrote:

> In principal it would act as any pre-declared value and is held in
> memory before the loop structure is encountered. As long as the
> person writing the scene code that utilizes this places the user
> prompts before anything else in the scene then you will only encounter
> the user prompt during the first few seconds of parsing activity.

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.
You could just ignore this problem and use a default value/expiry time 
system, but you still have to figure out how to get input from the user 
in a platform-independant way.
My idea would be a standard set of user input-output functions for POV 
4.0. These would be internal to the platform-specific part of the code 
and very general in action, and could be used for user interaction as 
well as things like #warning and #debug as well as prompt_user(). Since 
they would be part of the platform-specific code and called from the 
core code, the problems with making those modifications to the core code 
would be gone.

Or maybe something similar exists already, I admit I haven't looked at 
that part of the code.

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

Post a reply to this message

> > At this point, I'm wondering if there is *any*
> > feature-set change I could suggest for POV-Ray and get a favorable
> > response from you.
>
> I actually don't have any objection to the idea of interactive scene
> files, I just don't see how they could be done well in POV-Script and in
> POV-Ray.

	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.

> it would just be too difficult to implement in POV-Script 

	<disbelief> Huh? </disbelief>

> and impossible to implement in a cross-platform manner

	<amusement> Refer to ANSI C Standard: scanf(...) </amusement>

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

> but I don't think that is a good general solution.

	By your definition, there is no such thing as a general
	solution.

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

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

Post a reply to this message

> 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