Hi everybody!

I wonder if anyone has thought about doing a better way to do large scripts
in povray?
I've been thinking about it a lot lately, getting pretty bored with #macro's
where 90% of the code is diffrent #declare statements.
There realy should be a light C++ interpeter in povray. Nothing fancy, just
the basic statements, for(;;), while(), do..while() and so on. And when you
actualy want to create something you write something like:

cout << " sphere { <0,0,0>,1 } " << endl;

to output it to the temporary scene source file. This could also be used for
messages:

cout << debug << "X position: " << x << endl;

to output a debug message.

A snip from a small scene could look something like this:

#script
    float x = 0;
    for (int i = 0;i < 10;i++) {
        cout << "sphere {<" << x << ",0,0>,1" << endl;
        cout << debug << "Output sphere nr." i << " at <" << x << ",0,0>" <<
endl;
        x += 3;
    }
#end

An implementation with procedures would be nice to.

Well, food for thought anyway.

/Anders

Post a reply to this message

I have already suggested that a for() loop and increment and decrement operators
as a nice addition to the pov language. Another thing someone once said was that
there might be a way of removing #declare and just dive directly into making x
equal y.

//Example:

#for(i=0; i<10; i++)
 e=i*2;
 sphere {0,1 pigment {rgb sqrt(e)}
 e*=.1;
 box {e,-e pigment {red e}}
/*
 this is just a wierd suggestion that came right
 off the top of my head, but it gives you an
 idea of the benefits of simplicity that could
 be reaped.
*/
#end

--
Anthony L. Bennett
http://welcome.to/TonyB

Graphics rendered
by the Dreamachine.

Post a reply to this message

Removing the declare would be very difficult from the standpoint of the
parser since, if you have a variable by itself, POV interprets it as a
float identifier and not an assignment statement.  However, maybe a shortcut
like just putting a special character at the beginning would allow the parser
to know that it is an assignment. (like maybe a '%'.  Is that used elsewhere
in POV?)  Then you would use
  %e=i*2;
instead of
  #declare e=i*2;
and the compiler would still know what you're talking about.

I also still think we should always be able to redeclare anything as any
other type (maybe warnings should be issued, but not for float -> vector
conversions).

-Nathan

TonyB wrote:
> 
> I have already suggested that a for() loop and increment and decrement operators
> as a nice addition to the pov language. Another thing someone once said was that
> there might be a way of removing #declare and just dive directly into making x
> equal y.
> 
> //Example:
> 
> #for(i=0; i<10; i++)
>  e=i*2;
>  sphere {0,1 pigment {rgb sqrt(e)}
>  e*=.1;
>  box {e,-e pigment {red e}}
> /*
>  this is just a wierd suggestion that came right
>  off the top of my head, but it gives you an
>  idea of the benefits of simplicity that could
>  be reaped.
> */
> #end
> 
> --
> Anthony L. Bennett
> http://welcome.to/TonyB
> 
> Graphics rendered
> by the Dreamachine.

Post a reply to this message

Yeah, that would save some typing.

I see the same trend happening with povray as with the data analysis software
I'm writing for a client.   I had a nice simple scripting language for data
analysis and generating plots, but we found we needed "if" statements, then
"if-then-else" and then we needed "goto" - youch! try adding that to a parser
that wasn't designed for it - and now maybe text string variables, and ..., and
..., and ...

It seems that most script languages that try to keep simple end up growing all
the other features found in most programming languages.  So why not just adopt
an existing language, an object-oriented one, perhaps Python, and put all the
good stuff like geometric models, textures, lights, etc. into libraries of
classes?   This would allow unlimited possibilities for looping, calculating,
user-defined functions, debugging support, and more.

What would be the relative advantages of 1) just adding new keywords and
directives to povray's existing language;  2) expanding it so much that it
becomes a "real" language; and 3) giving up and using an existing outside
language, making 

-- 
Daren Scot Wilson
dar### [at] pipelinecom 
www.newcolor.com
----
"Unless we attempt the absurd, we cannot achieve the impossible" 
                                           - A. Einstein

"Unless we attempt to get out of bed, we cannot achieve the easy"
                                           - D. Wilson

Post a reply to this message

Daren Scot Wilson wrote:
> 
> Yeah, that would save some typing.
> 
> I see the same trend happening with povray as with the data analysis software
> I'm writing for a client.   I had a nice simple scripting language for data
> analysis and generating plots, but we found we needed "if" statements, then
> "if-then-else" and then we needed "goto" - youch! try adding that to a parser
> that wasn't designed for it - and now maybe text string variables, and ..., and
> ..., and ...
> 
> It seems that most script languages that try to keep simple end up growing all
> the other features found in most programming languages.  So why not just adopt
> an existing language, an object-oriented one, perhaps Python, and put all the
> good stuff like geometric models, textures, lights, etc. into libraries of
> classes?   This would allow unlimited possibilities for looping, calculating,
> user-defined functions, debugging support, and more.
> 
> What would be the relative advantages of 1) just adding new keywords and
> directives to povray's existing language;  2) expanding it so much that it
> becomes a "real" language; and 3) giving up and using an existing outside
> language, making
> 
> --
> Daren Scot Wilson
> dar### [at] pipelinecom
> www.newcolor.com
> ----

A few of my thoughts on your query:


Who will these changes serve ?

What percentage of the current user base will benefit from the proposed
changes and how many might suffer as a result ?

Will my 8 3/5 year old nephew still be able to use the program after these
changes are made ? ( I don't think so )

  By changing to a "real" programing language interface you will be
changing it into a programmers interface that takes specialized
programming skills to use rather than the simple parser description
language in use now. I don't believe you understand how important that
is for people that have no skills in programming.

  I read a newsgroup post somewhere a couple of months ago from a 55
year old new computer user with about 9 months total experience using
any kind of computer system. He could hardly contain his joy at having
been introduced to povray and while everything he tried was confusing
he felt that Pov was structured in such a logical way that it was only
a matter of time before he picked up speed.

  Personally I think such a change would make Povray more difficult for
non programmer people to use it and runs a very serious risk of excluding
a large part of the current user base. I have squat for programming
skills but am considered one of the advanced users in this group. If
you change it into a programming language interface you will turn me
into an instant newbie and I would in most likelihood abandon using
Pov as a result.

  By adopting a "real" programming language interface you will start
one of the largest wars known to the history of the program as to which
of the multitude of programming languages will be adopted as the most
flexible and the language of choice. Not insurmountable but it will
certainly never gain a total consensus by everyone.

  Let us not forget that the current level of simplicity is extended
to people from all walks of life, country of origin, and age group.
Also bear in mind the international flavour of this program and how
difficult it is for non english speaking people to understand even
the simple directives used in the text interface of the program due
to language barriers. If you adopt a program language interface and
abandon the current system you may increase that language barrier
even further.

  It may sound like I am being overly negative in my response but I
prefer that you accept them as rational and very real considerations.
When contemplating such a serious change to an already well established
program also keep in mind the Pov team and it's supporters have gone out
of their way to maintain consistency and backward compatibility throughout
it's long history and you are advocating something that would throw that
whole philosophy right out the window.

-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message

I don't always agree with you Ken but this time I do

Rather than make wholesale changes ask yourself this...What can't povray do?
then add it to the existing language.

Mick

Ken <tyl### [at] pacbellnet> wrote in message
news:3750D8F3.DDC25598@pacbell.net...
> Daren Scot Wilson wrote:
> >
> > Yeah, that would save some typing.
> >
> > I see the same trend happening with povray as with the data analysis
software
> > I'm writing for a client.   I had a nice simple scripting language for
data
> > analysis and generating plots, but we found we needed "if" statements,
then
> > "if-then-else" and then we needed "goto" - youch! try adding that to a
parser
> > that wasn't designed for it - and now maybe text string variables, and
..., and
> > ..., and ...
> >
> > It seems that most script languages that try to keep simple end up
growing all
> > the other features found in most programming languages.  So why not just
adopt
> > an existing language, an object-oriented one, perhaps Python, and put
all the
> > good stuff like geometric models, textures, lights, etc. into libraries
of
> > classes?   This would allow unlimited possibilities for looping,
calculating,
> > user-defined functions, debugging support, and more.
> >
> > What would be the relative advantages of 1) just adding new keywords and
> > directives to povray's existing language;  2) expanding it so much that
it
> > becomes a "real" language; and 3) giving up and using an existing
outside
> > language, making
> >
> > --
> > Daren Scot Wilson
> > dar### [at] pipelinecom
> > www.newcolor.com
> > ----
>
> A few of my thoughts on your query:
>
>
> Who will these changes serve ?
>
> What percentage of the current user base will benefit from the proposed
> changes and how many might suffer as a result ?
>
> Will my 8 3/5 year old nephew still be able to use the program after these
> changes are made ? ( I don't think so )
>
>   By changing to a "real" programing language interface you will be
> changing it into a programmers interface that takes specialized
> programming skills to use rather than the simple parser description
> language in use now. I don't believe you understand how important that
> is for people that have no skills in programming.
>
>   I read a newsgroup post somewhere a couple of months ago from a 55
> year old new computer user with about 9 months total experience using
> any kind of computer system. He could hardly contain his joy at having
> been introduced to povray and while everything he tried was confusing
> he felt that Pov was structured in such a logical way that it was only
> a matter of time before he picked up speed.
>
>   Personally I think such a change would make Povray more difficult for
> non programmer people to use it and runs a very serious risk of excluding
> a large part of the current user base. I have squat for programming
> skills but am considered one of the advanced users in this group. If
> you change it into a programming language interface you will turn me
> into an instant newbie and I would in most likelihood abandon using
> Pov as a result.
>
>   By adopting a "real" programming language interface you will start
> one of the largest wars known to the history of the program as to which
> of the multitude of programming languages will be adopted as the most
> flexible and the language of choice. Not insurmountable but it will
> certainly never gain a total consensus by everyone.
>
>   Let us not forget that the current level of simplicity is extended
> to people from all walks of life, country of origin, and age group.
> Also bear in mind the international flavour of this program and how
> difficult it is for non english speaking people to understand even
> the simple directives used in the text interface of the program due
> to language barriers. If you adopt a program language interface and
> abandon the current system you may increase that language barrier
> even further.
>
>   It may sound like I am being overly negative in my response but I
> prefer that you accept them as rational and very real considerations.
> When contemplating such a serious change to an already well established
> program also keep in mind the Pov team and it's supporters have gone out
> of their way to maintain consistency and backward compatibility throughout
> it's long history and you are advocating something that would throw that
> whole philosophy right out the window.
>
> --
> Ken Tyler
>
> mailto://tylereng@pacbell.net

Post a reply to this message

On Sat, 29 May 1999 23:21:39 -0700, Ken <tyl### [at] pacbellnet> wrote:

Reactionary Ken strikes a blow for for non-hackers!  I don't think the POV team
would commit the sacriledge of converting POV into a full blown programming
language "with added ray-tracing", but I'm glad Ken that you have fired a
warning shot.

Not that I am against programmability - it  was only when the team provided POV
with a selection of programming constructs that I saw POV as a seriously useful
plaything.  But any changes which get in the way of the primary purpose of the
program must be bad. (Please, team, concentrate on making media eaier to
predict, more controllable, more versatile and faster! )

OK, the programming features are limited and a bit verbose, but they give
tremendous scope and, as you say, Ken. POV-Ray is still accessible to people
with minimal programming skills.  Long may it remain so.
David
------------
dav### [at] cwcomnet
http://www.hamiltonite.mcmail.com
------------

Post a reply to this message

Case: the POV-Team adopts a new language. A very different one, a
programming language. I personally would probably attempt to learn it.
Provided I have the time, I would probably succeed, to a degree. Provided I
succeed, I would probably find POV more utile.

But.
What if I fail to meet any of those conditions? If I don't find the time, if
the new structure doesn't agree with my logic? I would, in effect, be forced
to abandon POV, since there is no going back; it's "learn the new language
or go".
I'm sure 90% of POV users, even the advanced users, would be in the same
situation. We would risk losing a lot of experienced people, and many
potential users. No, I don't think such burning-the-bridges approach is a
good one.

However, I would greatly approve of a similar, but less radical approach.
One that leaves alternatives.
Correct me if I'm wrong, but all the conditionals, arrays, macros etc. serve
one ultimate purpose: to generate and manipulate POV objects, textures etc.
Nothing that couldn't be duplicated with a (big) scene file with none of
those programming elements - just the objects et al.
One could create an alternative parser, that outputs such a scene file. This
way you would still have the option of the established language, but could
try out the functionality of the new one.
The question is, if anyone would be willing to create and maintain this
parser. To this question, I have no answer.

Margus

Post a reply to this message

On Sun, 30 May 1999 16:05:58 +0300, "Margus Ramst"
<mar### [at] peakeduee> wrote:

>However, I would greatly approve of a similar, but less radical approach.
>One that leaves alternatives.
>Correct me if I'm wrong, but all the conditionals, arrays, macros etc. serve
>one ultimate purpose: to generate and manipulate POV objects, textures etc.
>Nothing that couldn't be duplicated with a (big) scene file with none of
>those programming elements - just the objects et al.
>One could create an alternative parser, that outputs such a scene file. This
>way you would still have the option of the established language, but could
>try out the functionality of the new one.
>The question is, if anyone would be willing to create and maintain this
>parser. To this question, I have no answer.

It would be nice if one could "bolt on" a parser for a different
language, as with panorama.  Then one person could write a perl module
to do POV-ish things, another could provide for scheme scripting, and
still another could add python support.  I would be for such a thing,
because I think it would increase the power of the engine.  But it
will never happen, for two reasons:

1) doing so would fragment the language, in that I could have a really
cool object that you couldn't use because you hadn't installed the 
Haskell front-end to your copy of POV.

2) It would no longer be as portable. Many languages haven't been
ported to every platform that POV currently runs on.

These are both the same problems you encounter with plugins, and in
fact a new frontend would be a kind of plugin.

That leaves the "translator" approach, that takes say a Perl script
and outputs a POV scene file.  That would work, but you lose the
ability to implement the features people are asking for, like being
able to query the properties of existing objects.

Post a reply to this message

Whew! Relieved to hear this sort of thing. I was beginning to dread the
intensive improvement to my education which would be needed to use POV-Ray
in the future.
You know, there's always going to be the custom versions people will make.
Program away on the source if so desired. Who knows, I might be able to
use things like POV-Prog too someday. Just attempt at humor, no sarcasm
intended. Now I'm wondering what POV-Prog might be able to do though,
raytrace my Windows GUI perhaps? Not too bad then.


David Wilkinson wrote:
> 
> On Sat, 29 May 1999 23:21:39 -0700, Ken <tyl### [at] pacbellnet> wrote:
> 
> Reactionary Ken strikes a blow for for non-hackers!  I don't think the POV team
> would commit the sacriledge of converting POV into a full blown programming
> language "with added ray-tracing", but I'm glad Ken that you have fired a
> warning shot.
> 
> Not that I am against programmability - it  was only when the team provided POV
> with a selection of programming constructs that I saw POV as a seriously useful
> plaything.  But any changes which get in the way of the primary purpose of the
> program must be bad. (Please, team, concentrate on making media eaier to
> predict, more controllable, more versatile and faster! )
> 
> OK, the programming features are limited and a bit verbose, but they give
> tremendous scope and, as you say, Ken. POV-Ray is still accessible to people
> with minimal programming skills.  Long may it remain so.
> David
> ------------
> dav### [at] cwcomnet
> http://www.hamiltonite.mcmail.com
> ------------

-- 
 omniVERSE: beyond the universe
  http://members.aol.com/inversez/homepage.htm
 mailto://inversez@aol.com?Subject=PoV-News

Post a reply to this message

Nathan Kopp wrote:

>   %e=i*2;
> instead of
>   #declare e=i*2;

Why not

$e=i*2;

- like in Perl? :)

Umm...forget that...realised it's easier to hit '%' since the left hand most of the
time is resting just nearby the left Ctrl-key on the keyboard. (Which makes it easy to
press left Shift while hitting the '5' key)

-----------------------------------------------------------------
Mikael Carneholm
Dep. of Computer Science
Högskolan i Borås, Sweden

http://www.studenter.hb.se/~arch
E-mail: sa9### [at] idautbhbse

Post a reply to this message

Hi,

I think everything programmable which is added to POV-Ray should be
*optional*. You must simply look for a way to link a greater flexibility
(which is more complex) to the (relative) simplicity of the existing
language.
What I concretely mean is: You write script files in an easy interpreted
language ("pov script"?), and then you link them into your pov file. In the
script you may be able to access certain objects by name and change their
properties. This leads to the fact that you have to provide names for the
objects in the scene (if you want to use scripts, that is).

Here an example:

1. The pov scene file
#include "colors.inc"
...
#include "script.scr"
...
sphere {
  name "MySphere"
  <0, 0, 0>, 1
  pigment { Red }
}

2. The script file:
...
MySphere.center.x = 0.5;
MySphere.radius = a;
...
MyLightSource.media_attenuation = false;
etc.

The disadvantage is that a wholly new object structure would have to be
designed, since most object properties are not explicitly called by a name
but just written down, say the radius of a sphere.

That's it for today: Brad

Post a reply to this message

"Brad S. Freeman" wrote:

> Hi,
>
> I think everything programmable which is added to POV-Ray should be
> *optional*. You must simply look for a way to link a greater flexibility
> (which is more complex) to the (relative) simplicity of the existing
> language.

Exactly my opinion. New users and people that just want to use POV to describe
(more or less) "quick'n'dirty" static scenes must be able to do it exactly as
in version<=3 also in the future. They should _not_ be forced to learn object
orientation in order to use POV.

But, those who want to help to turn POV into a fully featured animation package
by writing easy-to-use include files, should be able to do this. And to do
this, OO is necessary as I see it. Note: ease-of-use is heavily dependant on
flexibility and accessibility(is that an english word?). For example, the
INI-file settings (parameters) need to be made accessible. For example, in
several situations I have wished that I could check if clock=Initial_Clock
(+KI).

- Mikael.

-----------------------------------------------------------------
Mikael Carneholm
Dep. of Computer Science
Högskolan i Borås, Sweden

http://www.studenter.hb.se/~arch
E-mail: sa9### [at] idautbhbse

Post a reply to this message

I can only agree with what Ken Tyler and other people already said. While the
current pov scripting is certainly a limitation in some ways, it is also
enabling a good number of people to express themselves *** because *** it
requires moderate programming skills. Think about BMRT : it's free, it's
(probably) a programmer's paradise, it has far more possibilities than POV, well
showed off on the examples in the BMRT home page (http://www.bmrt.org). Problem
is that these examples are almost the only BMRT pictures you can find around the
net. BMRT is just too difficult to learn for the average hobbyist. You can do
incredible things with it but actually few people do (not a criticism of BMRT,
it's a different logic that's all). Think now about the large number of POV
galleries. Some may be good, some may be less good, but all these people have
fun and enjoy themselves.
I really don't want POV to go the BMRT way, and become a magnificent, ideal,
perfect tool for the happy few. I'd rather keep it with all its well-known
shortcomings. There are surely lots of things I can't do with POV, but there are
also lots of things that I can do and still can't find the time to do.

Gilles Tran

Post a reply to this message

Mikael Carneholm <sa9### [at] idautbhbse> wrote:
> "Brad S. Freeman" wrote:
>
> > Hi,
> >
> > I think everything programmable which is added to POV-Ray should be
> > *optional*. You must simply look for a way to link a greater flexibility
> > (which is more complex) to the (relative) simplicity of the existing
> > language.
>
> Exactly my opinion. New users and people that just want to use POV to
describe
> (more or less) "quick'n'dirty" static scenes must be able to do it exactly
as
> in version<=3 also in the future. They should _not_ be forced to learn
object
> orientation in order to use POV.
>
> But, those who want to help to turn POV into a fully featured animation
package
> by writing easy-to-use include files, should be able to do this. And to do
> this, OO is necessary as I see it.

Yeah, this is exacly what I had in mind, I just forgot to write it in my
initial message. I'm not talking about changing the way standard pov scenes
are written, just how to make it easier for us who writes big macros and
they who use them. If you don't want to use it you can simply skip it and
I'm sure most people will.
What I'm looking for is a place in the scene/include where I can do pretty
much what I want and spend time on coding/scripting, not redeclaring a bunch
of variables and doing stupid #while loops. This could be done inside a
#code ... #end statement because then it wouldn't affect the syntax outside
in any way, and you shouldn't have any problem with adding it to the parser
(more than all the hard work it would take to do the parser/interpretater of
the script).

/Anders

Post a reply to this message

Dear All,

After having read the many other replies to this post there is not much else to say,
yet I think everyone forgot to mention one thing : The programmer skilled ones can
do what they feel by going directly the back door, that is to say by changing POV
code to do what they want. Since source code is available this is no problem.

In that respect I would advocate no big change to POV scene description language in
order to maintain current users au fait, good programmers will always be able to use
POV a different way should they so wish, beginner programmers will just have to
learn if they want to enhance POV's capabilities (I'm in that latter category as far
as POV is concerned).

Cheers,
Al.


TonyB wrote:

> I have already suggested that a for() loop and increment and decrement operators
> as a nice addition to the pov language. Another thing someone once said was that
> there might be a way of removing #declare and just dive directly into making x
> equal y.
>
> //Example:
>
> #for(i=0; i<10; i++)
>  e=i*2;
>  sphere {0,1 pigment {rgb sqrt(e)}
>  e*=.1;
>  box {e,-e pigment {red e}}
> /*
>  this is just a wierd suggestion that came right
>  off the top of my head, but it gives you an
>  idea of the benefits of simplicity that could
>  be reaped.
> */
> #end
>
> --
> Anthony L. Bennett
> http://welcome.to/TonyB
>
> Graphics rendered
> by the Dreamachine.

--
ANTI SPAM / ANTI ARROSAGE COMMERCIAL :
Pour me répondre, veuillez enlever le Z de mon adresse.
To answer me, please take out the Z from my address.

Post a reply to this message