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