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


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


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 :

To answer me, please take out the Z from my address.

Post a reply to this message