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