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