Hello,

For a good programming style you should declare your 'big complicated
expression' beforehand, like:

#declare big_complicated_expression = <some complicated expressions>;
#declare [big_complicated_expression] = [big_complicated_expression]+3;

because an array desciptors with complicated expressions are very
unreadable.

Yuors Axel Baune

Post a reply to this message

In article <38c8834b@news.povray.org>, "Thorsten Froehlich" 
<tho### [at] trfde> wrote:

> Either way, WASTE was not designed as an editor. It does a good job, 
> but adding such features as auto-completion is either done by a lot 
> of working around it or by some inside modifications and hooks.  It 
> is possible with reasonable work, but not a free feature :-(

Ah, thanks for clarifying that.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

In article <38C816BE.35E35A1C@hotmail.com>, Tor Olav Kristensen 
<tor### [at] hotmailcom> wrote:

> But what if the loop control variable is a vector that is shared
> between several nested loops? (See my example macro below.)
> 
> Would this be possible with nested for-loops?

It would be possible, but not necessarily the best way to do it. 
Something like this:


#macro ObjectSplit(Thing, Point1, Point2, nnv)
// Cuts an object into several "box"-parts
// Result is returned in an array of such parts

  //#local nnv = <nx, ny, nz>;
  #local ThingArray = array[nnv.x][nnv.y][nnv.z]
  #local dPoint = (Point2 - Point1)/nnv;

  #for(Cntv = <0,0,0>; Cntv.z < nnv.z; Cntv.z += 1)
    #for(Cntv.y = 0; Cntv.y < nnv.y; Cntv.y += 1)
      #for(Cntv.x = 0; Cntv.x < nnv.x; Cntv.x += 1)
        #local ThingArray[Cntv.x][Cntv.y][Cntv.z] =
          intersection {
            object { Thing }
            box { Point1 + dPoint*Cntv, Point1 + dPoint*(Cntv+Unitv) }
          }
      #end // for
    #end // for
  #end // for

  ThingArray

#end // macro ObjectSplit

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

Axel Baune <aba### [at] neuroinformatikuni-ulmde> wrote:
: The variant

:> > #declare A = A + B;
:> > #declare A = A - B;

: is far more readable than the other.

  In this case yes. But what about a longer identifier, like something
already suggested:

#declare ColorArray[ColorIndex][ColorSubIndex].red =
  ColorArray[ColorIndex][ColorSubIndex].red + 1;

or:

#declare ColorArray[ColorIndex][ColorSubIndex].red += 1;

  Note also that if one of the indices is a complex mathematical operation,
it would have to be calculated twice, instead of just once.
  Also if you have to modify the line, you would have to do it in two places
in the line instead of just one place.
  And you don't have to use the feature if you don't want to. The existance
of a feature doesn't make it mandatory to use it. I don't make a quartic
to get a torus although this possibility exists and is an inherent feature
in povray.

: Besides this it would comlicate the
: parser of PoV if the other variant should be maintained.

  Was this only a guess or do you really know that it will be conclusively
more complicated?

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

On 10 Mar 2000 07:58:40 -0500, Nieminen Juha wrote:
>Axel Baune <aba### [at] neuroinformatikuni-ulmde> wrote:
>: Besides this it would comlicate the
>: parser of PoV if the other variant should be maintained.
>
>  Was this only a guess or do you really know that it will be conclusively
>more complicated?

It had to have been a guess.  It wouldn't be that complicated to do.

-- 
These are my opinions.  I do NOT speak for the POV-Team.
The superpatch: http://www2.fwi.com/~parkerr/superpatch/
My other stuff: http://www2.fwi.com/~parkerr/traces.html

Post a reply to this message

Hello,

Ron Parker wrote:
> 
> On 10 Mar 2000 07:58:40 -0500, Nieminen Juha wrote:
> >Axel Baune <aba### [at] neuroinformatikuni-ulmde> wrote:
> >: Besides this it would comlicate the
> >: parser of PoV if the other variant should be maintained.
> >
> >  Was this only a guess or do you really know that it will be conclusively
> >more complicated?
> 
> It had to have been a guess.  It wouldn't be that complicated to do.

As I've never looked into the Code for the PoV-Parser I' did"t know
exactly, but I've already written a parser of my own for my programms,
and therefore I know what effects it would have on my own parser if I
wish to include the new syntax. From this knowledge I've extrapolated to
the PoV-Parser.

Yours Axel Baune

Post a reply to this message

Ken wrote:

> Would you have difficulty re-learning POV-Ray if it's language format
> changed ?
> Would you resent it or maybe even quit using the program completely ?

I believe that the first purpose of POV is to allow a large number
of people from very different educational backgrounds to make excellent
pictures for free. I'm also aware that an important part of the POV
community does not see POV as a mean to obtain pictures (i.e.
they don't see the resulting picture as a primary goal), but as a mean to
derive pleasure from the intellectual game of programming the pictures. In
fact, a good number of people enjoy programming POV itself rather
than doing images  : think for instance that some patches were
never documented until recently, as if the sole purpose of
the patch was its programming and not having other people using it.
Of course, the fact that some people are primarily interested in
programming POV is very fortunate otherwise there would be
no POV at all !

However, I'd like to point out that whatever faults programmers
can find in the current scene description language, it is also
because it is "faulty" that non-programmers can learn it,
enjoy it, and make pov popular. So there's a potential conflict
here, since programmers may differ from non programmers about
what a "good" feature is, and what "faulty" means.

One interesting comparison can be made with BMRT : BMRT is free,
it uses an industry standard (RIB), it is (supposedly) immensely
powerful and its output,as far as I know, is very good.
But you won't find many BMRT pictures around (just look at the
IRTC) and the ones I've seen so far are of the "impressive feature
demonstration" kind. I guess that's because BRMT's
quality is obtained at the expense of it being programmer-oriented.

Now everyone can download POV, and run immediately a demo
scene which is written in something understandable for the non-programmer
type (in the Windows version this is automatic).
In a couple of seconds, you can change something in the code
without looking at the manuel and lo, here's your first scene.
It's not 100% intuitive, but it's not difficult either.
That's how I got started, and I supposed lots of people got
hooked like that. I'd like to keep this "philosophy" alive with POV,
because this is what makes it unique.

Of course I don't want to be conservative : POV can (should) evolve.
But my personal wish list is made of features that would make the
user's life easier in terms of creation (like a really
fast Cloud layer object, à la Terragen, for instance, or the direct
support of some popular mesh formats, or a simple way to make
patina and cracks, or built-in "fur" and "tree" engines etc.).
I have to recognize that some programming features (like arrays
or macros) that seemed complex at the beginning (yes, for a
non-programmer, even arrays are complex !) proved themselves
very useful. My current concern, which I seem to share with
Ken Tyler, is that many of features I've seen on programmers'
"wish lists" looked like they would surely improve the lives
of programmers and possibly make pov faster, or more flexible,
but that they would also make a few non-programmers cringe.
For instance, some people may have fun browsing a 500-page
long manual on OO programming, some others don't.

Would there be better pictures ? In many cases, theoretically yes.
But the people who advocate these changes should think about
the potential risk of reducing POV's user basis, since
the probability of having talented users using the new
advanced features, or using POV at all, would also be reduced,
what I'd call the "BMRT syndroma". In some cases, I'm under
the impression that the proposed changes are for the
sake of "proper" programming only, or for POV becoming closer
to the C language, with no real concern about the way
non-programmers actually use POV. I'm not sure that
maintaining several forms of the language (the regular and the new
one) would be very practical, both for users and POV developpers
(is backward compatibility really fun to maintain ?). Having
several ways to express the same idea/object/whatever would
make things very confusing for many users (and a larger manual
harder to read and maintain).

To answer Ken's questions, I surely would experience trouble if
the language changed completely. I've got my own legacy of scenes
(which already hard to maintain due to version changes and
immoderate patch use), and I'm able to work fast because I
know my way in POV (provided the help file is open !).
So having a new language format would be like using a
new software : I would take the trouble to learn it only if
it was clearly "competitive", in terms of user-friendliness
and features, over the current POV implementation.

Gilles Tran

Post a reply to this message

Axel Baune <aba### [at] neuroinformatikuni-ulmde> wrote:
: As I've never looked into the Code for the PoV-Parser I' did"t know
: exactly, but I've already written a parser of my own for my programms,
: and therefore I know what effects it would have on my own parser if I
: wish to include the new syntax. From this knowledge I've extrapolated to
: the PoV-Parser.

  Perhaps you didn't do it the right way ;)

  Using something like yacc and lex makes it quite easy to add new syntax.
Although povray doesn't use them, it might use something similar (I really
don't know).

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Gilles Tran <tra### [at] inapginrafr> wrote:
: I'm also aware that an important part of the POV
: community does not see POV as a mean to obtain pictures (i.e.
: they don't see the resulting picture as a primary goal), but as a mean to
: derive pleasure from the intellectual game of programming the pictures.

  Music to my ears... :)


-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

If you use the C style of for() loop, you can do more than just fixed
step incrementing/decrementing, though if I understand you correctly you
don't seem to like that.
I've seen some pretty ugly for() loops in C.
This is getting away from the gist of the thread though.  Adding more
control statements to POV would not make the language more difficult for
non-programmers, it would just make it more powerful for those who wish
to use those features for scene construction.

BTW is there any real reason for all those #s?
Would anything break if they were made optional?

PoD.

Post a reply to this message

In article <38C8DD71.3560294C@neuro.informatik.uni-ulm.de>, Axel Baune 
<aba### [at] neuroinformatikuni-ulmde> wrote:

> The variant
> 
> > > #declare A = A + B;
> > > #declare A = A - B;
> 
> is far more readable than the other.

I disagree. I find this syntax:
#declare NumOfParts += PartsAdded;
#declare NumOfParts -= PartsRemoved;

much easier to read than:
#declare NumOfParts = NumOfParts + PartsAdded;
#declare NumOfParts = NumOfParts - PartsRemoved;


I read the += operator as saying "add B to A", instead of "set variable 
A to the result of adding A and B". It is a special case, and while more 
limited, makes code more readable since you know exactly what the code 
is intended to do.
Also, shorter expressions are almost always more readable than longer 
ones, even if the longer one is theoretically "cleaner".(within certain 
limits, of course. Warp's sig is not an example of shorter==better.) And 
the duplicated portion can often get quite large, even when it can't be 
put in a separate variable(I very rarely use single character names, I 
usually only use them for loop counters.).


> Besides this it would comlicate the parser of PoV if the other 
> variant should be maintained. This will lead to a new type of 
> possible parser bugs.  

As has already been said by others, this isn't true.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

In article <38C8DC47.1BEAFE1C@neuro.informatik.uni-ulm.de>, Axel Baune 
<aba### [at] neuroinformatikuni-ulmde> wrote:

> From the viewpoint of a computer scientist (I'm one) this is a not a
> syntactically correct defiend for-loop. The variable of a for-loop
> belongs to the for-command and should be never _changable_ by the user. 

Why? I see it as just another specialized structural component, which 
should be used when it is appropriate. Your restriction on modifying the 
loop variable seems arbitrary...
You say you are a computer scientist, but are you a computer programmer? 
I am still inexperienced with programming(I've only done a couple 
particle simulators and a few POV patches), but I can't think of any 
reason the loop variable shouldn't be used except for counting.

Maybe if you defined a for loop as a block of code that is executed a 
fixed number of times...but then, why have an initializer and an 
increment statement? Your for loop should only take one parameter(the 
number of times to loop) and should always increment by 1. You could use 
this to do everything an ordinary for loop with your restriction could 
do...
It is just that your definition seems to be going to an extreme(the 
other extreme being only using goto. :-) ).


> Sorry for flaming, but this are the programming styles, which make
> software packages difficult to maintain, debug, readable and
> understandable by other programmers.

How is it hard to understand?

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

In article <38c8c65d@news.povray.org>, Nieminen Juha 
<war### [at] sarakerttunencstutfi> wrote:

>   I think that there should some struct-type and reference-type data 
>   types.
> This would allow, for example, making linked lists.

I think union could be used for this if the ability to bind variables 
and macros to objects was added. I would also like to see a pointer-like 
feature added(with checking for valid accesses, of course). I think this 
is what you meant by "reference-type data types". Probably something to 
think about for POV 4.0...(or 4.1) :-)

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

PoD wrote:
> 
> Some aspects of the language which relate purely to programming could be
> changed or (probably better) extended without affecting those who don't
> use them.
> 
> For a non-programmer or a programmer , macros, loops etc are a lot
> harder in POV than the equivalents in most programming languages.
> 
> Surely replacing
>   #declare I=1; #while(I<=5) ... #declare I=I+1;#end
> with either
>   for I = 1 to 5 {...}
> ala Basic, or even for a non-programmer,
>   for( I=1; I <= 5; I=I+1){...}
> would make life easier for all.

	So what is the difference other than a different syntax? The 123
ways to create a loop? They all do the same thing in the end.
Even step = 3 with I=I+3. 

	Introducing additional syntaxes raises more problems than it
solves. With one elementary syntax that can do everything there
isn't nearly as much to read and a hundred fewer places for
parser differences to creep in. 

	Next, complex conditional if then else statements. Can GOTO be
far behind?

Post a reply to this message

Johannes Hubert wrote:
> 
> "ingo" <ing### [at] homenl> wrote in message
> news:8EF2B8E07seed7@204.213.191.228...
> > Nieminen Juha wrote:
> >
> > >#declare A += B;
> > >#declare A -= B;
> >
> > What does it mean?
> 
> the same as
> 
> #declare A = A + B;
> #declare A = A - B;

	OK. Any what is the value beyond saving a few keystrokes? 

	The time required for extra keystrokes is the last thing that
worries even the best of programmers.

Post a reply to this message

In article <38C992EA.4C6238BD@ij.net>, Matt Giwer <jul### [at] ijnet> 
wrote:

> 	So what is the difference other than a different syntax? The 123
> ways to create a loop? They all do the same thing in the end.
> Even step = 3 with I=I+3. 
> 
> 	Introducing additional syntaxes raises more problems than it
> solves. With one elementary syntax that can do everything there
> isn't nearly as much to read and a hundred fewer places for
> parser differences to creep in. 

The only difference is syntax. But that is a meaningful difference. 
Although a for loop could also be implemented as a while loop, it can 
sometimes be easier to write and understand if written as a for loop.

And what do you mean by "a hundred fewer places for parser differences 
to creep in"? I don't think the modifications would be very extensive, 
and there is only one parser.


> 	Next, complex conditional if then else statements. Can GOTO be
> far behind?

Umm, we have if-then-else statements. And switch statements. And goto is 
a bad idea for many reasons.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

In article <38C994D0.C4A06309@ij.net>, Matt Giwer <jul### [at] ijnet> 
wrote:

> > #declare A = A + B;
> > #declare A = A - B;
> 
> 	OK. Any what is the value beyond saving a few keystrokes? 
> 
> 	The time required for extra keystrokes is the last thing that
> worries even the best of programmers.

Better readability, code which is easier to maintain without introducing 
new bugs, etc. The examples given make using = and + look good, but they 
also use single-character variable names. Just about the only time I use 
single-character variable names is in loop counters, most of the time 
the names are longer. Add in using multidimensional arrays, and you 
quickly get to line lengths that are very difficult to keep track of and 
modify later.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

Nieminen Juha wrote:

> Axel Baune <aba### [at] neuroinformatikuni-ulmde> wrote:
> : As I've never looked into the Code for the PoV-Parser I' did"t know
> : exactly, but I've already written a parser of my own for my programms,
> : and therefore I know what effects it would have on my own parser if I
> : wish to include the new syntax. From this knowledge I've extrapolated to
> : the PoV-Parser.
>
>   Perhaps you didn't do it the right way ;)
>
>   Using something like yacc and lex makes it quite easy to add new syntax.
> Although povray doesn't use them, it might use something similar (I really
> don't know).

Well, using something like XML rules would make it much easier to parse.
Unfortunately POV-Ray's language and parser are not designed quite that way.
After the change for 4.0, maybe it will end up a little more extensible.

--
"My new computer's got the clocks, it rocks
But it was obsolete before I opened the box" - W.A.Y.

Post a reply to this message

An evolution to a Basic like syntax would be OK.

Object Oriented - heaven help us!!  The programmers (some) might like this
but I think the rest of us casual users would be driven away.

--
Jim

Check out my web site  http://www.kressworks.com/

Ken <tyl### [at] pacbellnet> wrote in message
news:38C7685C.5A4F3A68@pacbell.net...
>
>
> Greetings,
>
>   As we all know the language used by POV-Ray is not only easy to use
> but offers a lot of flexibility. There are often many ways to describe
> an object or attribute of an object because of the "looseness" of
> it's language.
>
>  Now many in the past have argued that it is too primitive for thier
> needs and suggest that it become more of an official programming
> language. They also suggest it should become more object oriented
> or stricter rules should be applied to the language from what it is
> now. Some say the syntax is too loose for all practical purposes.
> Some even suggest it should move to a binary format that needs to
> be compiled before being parsed (heaven forbid).
>
>  I say the one thing that attracted me to POV-Ray was the fact that
> it's text based input was both easy to learn, was intuitive from the
> beginning, and I never had to learn a programmers language to use
> the program. I like the way that you can describe something in several
> ways to achieve the same results. In my opinion this loose and very
> flexible language makes it a very powerful program to use.
>
>  What I do worry about though is the influence that the people who seek
> a more programmer like language may have for the mass of people that have
> no programming background but still enjoy using the program. It might
> be good for them in some circumstances but would it be good for everyone
> is not so cut and dried as it were.
>
>
> So the questions I have are really for the non-programmer types out there.
>
> Would you have difficulty re-learning POV-Ray if it's language format
> changed ?
>
> Would you resent it or maybe even quit using the program completely ?
>
>
>
> P.S. I am not suggesting that the POV-Team is even considering changing
>      the language at this time. I am mearly trying to find out what the
>      mainstream users of the program think about this and if they really
>      like the way the syntax is currently structured.
>
>
> --
> Ken Tyler -  1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
> http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

Jim Kress wrote:

> An evolution to a Basic like syntax would be OK.
>
> Object Oriented - heaven help us!!  The programmers (some) might like this
> but I think the rest of us casual users would be driven away.

No. No. Really. OO for POV-Ray would be nice.

Trust me.  :-)


In all seriousness, object oriented would work very well for POV-Ray, since it
models... objects!

If you are hand-coding POV-Ray, then you have to start thinking about the
objects you are making, primitives, meshes, etc. and where they go and how they
interact and what properties they have...

It's already a little OO, but going more so in the proper manner (notice I just
said "in the proper manner") might help greatly.


For those who learn other types of programming first, OO gets a little
difficult to pick up. But I believe that in general learning OO as a first
language is easier.

There are cases where an OO language might not be appropriate, but since the
concepts in POV-Ray are already so similar, it makes OO a good choice for
POV-Ray. Many of the concepts that make learning an OO language 'more
difficult' than learning VB are concepts that need to be learned for POV-Ray
itself.

OO was also used by Macromind in their Lingo in Director. Director was
definitely not for programmers but for designers. For their needs, it was very
good.

--
"My new computer's got the clocks, it rocks
But it was obsolete before I opened the box" - W.A.Y.

Post a reply to this message

Chris Huff wrote in message ...
>In article <38C992EA.4C6238BD@ij.net>, Matt Giwer <jul### [at] ijnet>
>wrote:
>> Next, complex conditional if then else statements. Can GOTO be
>> far behind?
>
>Umm, we have if-then-else statements. And switch statements. And goto is
>a bad idea for many reasons.


In "The Art of Computer  Programming", Knuth uses a GOTO in one of the
algorithms, simplifying things greatly.

Mark

Post a reply to this message

Mark Wagner wrote:

> Chris Huff wrote in message ...
> >In article <38C992EA.4C6238BD@ij.net>, Matt Giwer <jul### [at] ijnet>
> >wrote:
> >> Next, complex conditional if then else statements. Can GOTO be
> >> far behind?
> >
> >Umm, we have if-then-else statements. And switch statements. And goto is
> >a bad idea for many reasons.
>
> In "The Art of Computer  Programming", Knuth uses a GOTO in one of the
> algorithms, simplifying things greatly.
>
> Mark

And that was one out of how many? And by a 'Master' also. Only for the
advanced.   :-)

--
"My new computer's got the clocks, it rocks
But it was obsolete before I opened the box" - W.A.Y.

Post a reply to this message

"Axel Baune" <aba### [at] neuroinformatikuni-ulmde> wrote in message
news:38C8DC47.1BEAFE1C@neuro.informatik.uni-ulm.de...
>
> Johannes Hubert wrote:
> >
> >
> > For example:
> >
> > for (I = 1; I <= something; ) {
> >     // loop body here
> >     I += non_deterministic_increment;
> > }
>
> From the viewpoint of a computer scientist (I'm one) this is a not a
> syntactically correct defiend for-loop.

Since we seem to look at details now (not to say beginning to split
hairs), I have to point out, that you are wrong: The "for" loop is
syntactically absolutely correct (in the languages C, C++, Java at
least) - on the *syntax* level there is nothing wrong with it.

However:

> Sorry for flaming, but this are the programming styles, which make
> software packages difficult to maintain, debug, readable and
> understandable by other programmers.

With this I may agree. I have never (as far as I can remember) actually
used a loop like this. I would rather use a while-loop for stuff like
that.
The point was to shows that a C/C++/Java style for-loop *can* change its
looping index.

Johannes.

Post a reply to this message

"Axel Baune" <aba### [at] neuroinformatikuni-ulmde> wrote in message
news:38C8DAB2.3BE14CC3@neuro.informatik.uni-ulm.de...
>
> No, I don't think so. In most programming languages the state of the
> variables used in a for-loop are undefined outside the loop, but most
> programmers ignores this and use the mostly undocomented feature, that
> after the for-loop the variable has the value of the variable in the
> last loop incremented by the specified step.

Not really correct either. You are probably thinking of C++, where the
ISO/ANSI standard says that a variable declared (and initialized) inside
of the for-statement is defined only in the statement and the block that
belongs to it. A fact that is still ignored by most compilers (the
standard is still kind of fresh).

But:

This is true only for for-loops like this one:

    for (int i = start; i != end; i++) {
    }

If you rewrite the loop like this:

    int i;
    for (i = start; i != end; i++) {
    }

then there is no ambiguity about if or if not "i" is defined after the
loop and which value it has. It *is* defined and *has* the value
assigned to it during the last executed operation that modified it.

Johannes.

Post a reply to this message

"Jim Kress" <jim### [at] kressworkscom> wrote in message
news:38c9cb32@news.povray.org...
> An evolution to a Basic like syntax would be OK.
>
> Object Oriented - heaven help us!!  The programmers (some) might like
this
> but I think the rest of us casual users would be driven away.

I must agree with Jon (see his post). Your message shows a "fear" of the
conecept of "object oriented" that is totally unfounded.
I guess it is porbably mostly fueled by the fact that OO is such a
buzzword, and by (not very good) programmers that have learned
procedural programming and or now too afraid, too lazy or too snobbish
to learn something else, and thus give OO a stigma of "new and complex
and difficult to learn, with no real advantages" just to justify the
fact that they don't even want to look at it.

I am convinced that learning OO programming is in many cases easier than
learning procedural programming (if you are not already "spoiled" by a
procedural language) - and for POV OO would be perfect - easy to
understand and learn and very powerful.

I'm very interested how Mikael's work will turn out. Maybe POV-Ray will
go the way of C++? (meaning *not* that the language becomes like C++,
but that it will be an object oriented language that contains backwards
compatibility to the old language, like C++ contains good old C).

Greetings,
Johannes.

Post a reply to this message

Gilles Tran wrote:

> Of course I don't want to be conservative : POV can (should) evolve.
> But my personal wish list is made of features that would make the
> user's life easier in terms of creation (like a really
> fast Cloud layer object, à la Terragen, for instance, or the direct
> support of some popular mesh formats, or a simple way to make
> patina and cracks, or built-in "fur" and "tree" engines etc.).

Here I will definitely agree with you. I would like to see procedural
features added that ease the creation of scene building without having
to resort to adding difficulty to the language itself. If you look at
the wealth of plug-ins available for 3DS Max you will see that they
offer some powerful features, that are easy to use, and the functions
that make them work are transparent to the user. The question that
needs to be asked is if the program exists for programmers or if it
exists for users who don't care how it works so long as it does.

> I have to recognize that some programming features (like arrays
> or macros) that seemed complex at the beginning (yes, for a
> non-programmer, even arrays are complex !) proved themselves
> very useful. My current concern, which I seem to share with
> Ken Tyler, is that many of features I've seen on programmers'
> "wish lists" looked like they would surely improve the lives
> of programmers and possibly make pov faster, or more flexible,
> but that they would also make a few non-programmers cringe.
> For instance, some people may have fun browsing a 500-page
> long manual on OO programming, some others don't.

Good point(s). What I also fear is that if the programming language
is extended in POV-Ray to include OO programming, for () loops, and
all of the other programming suggestions that have been addressed
in this thread, is what is going to happen when some non programming
literate POV-User comes to the news groups seeking help and some
programmer type gives them an example in the form of these new
features ? The programmer types (and there a lot of them here in the
groups that answer questions on a regular basis) will quickly adopt
the attitude that everyone thinks like them and give examples in
their language style of choice, while the real truth of the matter
is that they could express themselves in a way that the people
seeking help will not understand a word they are saying.

> To answer Ken's questions, I surely would experience trouble if
> the language changed completely.

I would probably not use the new version if it became to hard to
learn. This would restrict me to using the older versions of the
program and I would miss out on new features.

> I've got my own legacy of scenes
> (which already hard to maintain due to version changes and
> immoderate patch use), and I'm able to work fast because I
> know my way in POV (provided the help file is open !).
> So having a new language format would be like using a
> new software : I would take the trouble to learn it only if
> it was clearly "competitive", in terms of user-friendliness
> and features, over the current POV implementation.

I agree here too. I have more .pov files that you can shake a stick
at and I am comfortable now, after hundreds of hours of using the
program, with it's current language structure.

-- 
Ken Tyler -  1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

I understand your arguments and can see how many of them may be true.

However, I am not really convinced. It *may* be true that creating a
more stringent and defined "language" may scare away users. However, I
don't know if this has to be so. If the language is designed carefully,
with "non-programmer" users in mind, it may become more accessible.
This doesn't necessarily have to mean that the new language resembles
any given programming language. It could be defined in its very own way
instead.

I have the impression, that the POV-Script has (in places) grown from
some ad-hoc decisions, and is therefore (in places) bloated and not very
logical.
Example: The fact that many keywords begin with a "#". This is a typical
sign for that the person who designed the initial language and parser
did not really know too much about parsers (I hope I am not stepping on
too many toes here, because I am speculating...) The "#" makes the
keywords easier to find for the parser, an approach intuitive for many
people who are confronted with writing a parser for the first time and
don't know better. However, parser technology has for a long time been
very advanced, and there is really no need for such "crutches" to make
parsing easier.
Note: I am not saying that POVs parser is bad, since it has had a long
time to evolve. I am only pointing out the "#" as a thing that has
probably been introduced ad-hoc in one of the very first versions, and
has since been carried with the language, without having much effect
besides making the script harder to read. An example for the "bloat" I
mentioned.

I agree with Ken's assessment that it is nice to have so many different
ways to achieve the same thing. I like that too. However, to have this,
there is no need for a bloated language. Take Java for example: Newly
designed and relatively "lean" it still offers many ways to do the same
thing (and I am *not* advocating to make the POV-Script like Java! this
is just an example...).

I think that "cleaning out the undergrowth" in the language (and adding
some OO features on the way) can have positive effects both for the
"programmer" and "non-programmer" users,
_if_done_in_a_carefully_thought_through_way_!
The "programmers" will find themselves more at home in the POV-language,
and the old problem of the difficulty to parse POV-Script (no program
besides POV really can) would also be solved.
And the "non-programmers" would get a language for which the manual
would actually be *thinner* than it is now, a language that is more
approachable and easier to learn (because frankly I think, that many of
you here who advocate POV-Script as an easy language to learn have lost
perspective a bit, since you alreay *know* POV-Script: sure, newbies
*can* learn POV-Script, but the language is far from being easy to learn
and could be much more so in my opinion).

The key is: Such a redesign of the language must be very well thought
through. A quick-shot solution (with focus only on making POV more like
a "standard" programming language) is not a good solution. And also
backwards compatibility to the old script needs to be maintained, so
that the old scenes are not lost in limbo.

So far,

Johannes.

Post a reply to this message

Johannes Hubert wrote:

> And the "non-programmers" would get a language for which the manual
> would actually be *thinner* than it is now, a language that is more
> approachable and easier to learn (because frankly I think, that many of
> you here who advocate POV-Script as an easy language to learn have lost
> perspective a bit, since you alreay *know* POV-Script: sure, newbies
> *can* learn POV-Script, but the language is far from being easy to learn
> and could be much more so in my opinion).

That is a dangerous assumption. I am painfully aware of the problems
I had learning the scripting language in POV-Ray. I think you would
be surprised to learn I had more problems thinking in terms of 3D than
I did learning POV's scripting language. Sure it took some time to
learn what sequence and order items should be placed in the scene file
but it took me much longer to learn position, object control, and
CSG operations than it did the syntax peculiarities. I also think
that the difficulties of learning any new proceedure or scripting
language will be unique for each user of the program. It's like the
guy with a 6th grade education who can do a valve job on a newer
Mercedes and the guy with a college education who can't figure out
how to change the windshield wiper blades.

-- 
Ken Tyler -  1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

Hmm, I want to add and stress a few points:

During this discussion I have felt a strong polarization between two
main types of contributors:

Experienced "non-programming-type" POV-Ray users (like Gilles and Ken)
presenting the view that POV-Script as it is now is easy to learn and is
perfect for newbies and non-programmers.

On the other side:
Experienced "programmer-type" POV-Ray users that are not satsified with
the language style of the POV-Script and that claim that adding more
"programming-language-like" features would help.

I think this is too much black-and-white:

The truth is probably somewhere in-between: POV-Script is not easy for
newbies, no matter what the POV-Script veterans that have become
accustomed to it think. And redoing the script to a programming language
will not help either.

A "best-of-both-worlds" approach would be needed: Use the decades of
experience and "best-practices" that have accumulated in the field of
designing good programming languages, and combine them with a good
portion of usability for "non-programming-type" users and their
experiences with the POV-Script AND keep the result backwards
compatible.

(And only to have this buzzword in my post too: I think that you don't
even have to go looking for an OO-solution if you try to do this,
because it will come looking for you, since POV already *is* inherently
object oriented.)

Johannes.

Post a reply to this message

"Johannes Hubert" <jht### [at] mailacom> wrote in message
news:38ca2192@news.povray.org...
| Example: The fact that many keywords begin with a "#". This is a typical
| sign for that the person who designed the initial language and parser
| did not really know too much about parsers (I hope I am not stepping on
| too many toes here, because I am speculating...) The "#" makes the
| keywords easier to find for the parser, an approach intuitive for many
| people who are confronted with writing a parser for the first time and
| don't know better. However, parser technology has for a long time been
| very advanced, and there is really no need for such "crutches" to make
| parsing easier.

I had to wonder about your viewpoint on this for a moment but my sentiments lean
toward the hashmark (#) as being one of the things that shows the person, not
the parser alone (however that works), where each of those special keywords are.
In fact they tend to be of prime importance so it's very good to know where they
are located.  Something you can do a search for easily too and can find all, not
just one, of the pertinent keywords.
This fact leads me to believe it might be good to have more such referencing
symbols for particular actions.  At least that's one way to look at it.  I think
I might get lost in a pov script having no special symbols, it can be such a
visual cue.
Anyway, I agree with Ken's remarks about the programmer/non-programmer thing a
lot.  But what may be getting overlooked is how POV has a programmer language of
sorts simply by being what it is: textual interface.  The continuance of that
into more features isn't the issue I'm sure, it's the syntax that is the hub of
this discussion.  By that reasoning it should not ever be a hard-core
programming language, instead it should always be a common vocabulary most of
all.

Bob

Post a reply to this message

"Ken" <tyl### [at] pacbellnet> wrote in message
news:38CA2519.7A4AFCB5@pacbell.net...
>
> That is a dangerous assumption. I am painfully aware of the problems
> I had learning the scripting language in POV-Ray. I think you would
> be surprised to learn I had more problems thinking in terms of 3D than
> I did learning POV's scripting language. Sure it took some time to
> learn what sequence and order items should be placed in the scene file
> but it took me much longer to learn position, object control, and
> CSG operations than it did the syntax peculiarities. I also think
> that the difficulties of learning any new proceedure or scripting
> language will be unique for each user of the program. It's like the
> guy with a 6th grade education who can do a valve job on a newer
> Mercedes and the guy with a college education who can't figure out
> how to change the windshield wiper blades.

All this nonewithstanding, I still think that POV-Script could be
defined in a way that it makes it even easier to learn.
The fact that *you* had more problems with the 3D than with the syntax
doesn't mean that there may be others for which it is the other way
round.
And the fact that *you* didn't have too many problems with the syntax at
all doesn't mean, that maybe even *you* might have had even fewer
problems with a different POV-Script.

It all comes back to my second post: This is not a black or white issue,
but one where the best middleground should be found.

Johannes.

Post a reply to this message

Johannes Hubert wrote:

> It all comes back to my second post: This is not a black or white issue,
> but one where the best middleground should be found.

It is good that we warriors from different tribes can come together
on the battle field and let the other know what it is that we are
fighting for. Without discussion there can be no truce.

<g>

-- 
Ken Tyler -  1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

Johannes Hubert wrote:

> And the "non-programmers" would get a language for which the manual
> would actually be *thinner* than it is now, a language that is more
> approachable and easier to learn (because frankly I think, that many of
> you here who advocate POV-Script as an easy language to learn have lost
> perspective a bit, since you alreay *know* POV-Script: sure, newbies
> *can* learn POV-Script, but the language is far from being easy to learn
> and could be much more so in my opinion).

It's obvious that there's a general consensus about the fact that the pov
syntax,
having evolved from a simple scene description language to a "programming"
language has now problems of its own. And you're right, it was never easy to

learn, and I know of people who downloaded pov and were scared right away.
However, I think that the original construct "primitive transform texture",
written in such a way, is very intuitive. I know of teachers who use it at
school
to teach maths to kids. I guess it's intuitive because it's close to actual
language :
"the sphere is big and blue".

My own ventures in OO programming and other advanced programming indicate
that, though there's no discussion on the necessity of it when it comes to
programming efficiency, it also requires a *much higher* level of abstract
thinking.
This may be natural to full-time programmers, but for many people
(including me) these ways of thinking are extraordinary hard, if not
impossible, to grasp. Many of the concepts discussed in this thread
(or in the programmers' wish lists) are simply out of my intellectual reach.

I don't remember having much trouble learning Basic or Fortran,
or the pov language : none of them was simple, mostly because of the
keywords to learn and remember, but nothing seemed outlandish.
But, after many years, I *still* have difficulty using something as simple
as MS Access Basic and I'm *still* confusing methods with properties,
for instance. Possibly, somebody with absolutely no programming background
would have no trouble at all, (because of the absence of old programming
habits) but frankly I doubt it.

So, yes, as you  say, a middleground should be found, and it should take
into account the fact that a pov user (according to my own conception
of pov of course) shouldn't have a PhD, or at least be a professional
programmer, to use it.

G.

Post a reply to this message

In article <38c9e8bc@news.povray.org>, "Mark Wagner" 
<mar### [at] gtenet> wrote:

> In "The Art of Computer  Programming", Knuth uses a GOTO in one of the
> algorithms, simplifying things greatly.

That was one case, out out of how many switch and if-then-else 
statements? The goto statment is very rarely needed, I don't think we 
are likely to run across one of those cases in something like POV.
And like Jon Cruz said, "Only for the advanced.". Since I don't consider 
myself advanced, I just avoid it like the plague. I have yet to run 
across a situation I need it...

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

Chris Huff wrote:
> 
> In article <38c9e8bc@news.povray.org>, "Mark Wagner"
> <mar### [at] gtenet> wrote:
> 
> > In "The Art of Computer  Programming", Knuth uses a GOTO in one of the
> > algorithms, simplifying things greatly.
> 
> That was one case, out out of how many switch and if-then-else
> statements? The goto statment is very rarely needed, I don't think we
> are likely to run across one of those cases in something like POV.
> And like Jon Cruz said, "Only for the advanced.". Since I don't consider
> myself advanced, I just avoid it like the plague. I have yet to run
> across a situation I need it...

Strangely the GOTO command is one of the few in Qbasic I ever understood
how to use successfully... Imagine that !

-- 
Ken Tyler -  1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

In article <38CA4E30.DAF9FB3E@pacbell.net>, lin### [at] povrayorg 
wrote:

> Strangely the GOTO command is one of the few in Qbasic I ever understood
> how to use successfully... Imagine that !

It isn't difficult to understand, it just usually leads to poorly 
designed and hard to read "spaghetti code". It can be used to do 
anything the #while loop and some of what #macro's can do, but the code 
becomes almost impossible to understand. There are cases where it can 
make a chunk of code(in C/C++/Java and probably the newer BASIC's) 
easier to understand, but those are quite rare.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

In article <38CA2128.BD294B07@pacbell.net>, lin### [at] povrayorg 
wrote:

> Here I will definitely agree with you. I would like to see procedural
> features added that ease the creation of scene building without having
> to resort to adding difficulty to the language itself. If you look at
> the wealth of plug-ins available for 3DS Max you will see that they
> offer some powerful features, that are easy to use, and the functions
> that make them work are transparent to the user. The question that
> needs to be asked is if the program exists for programmers or if it
> exists for users who don't care how it works so long as it does.

I am not sure if some of these things, like cloud objects, fur, trees, 
etc, would be a good language feature. It would be faster parsing, but 
that is about it. It would be more difficult to modify, if you want to 
customize it you would have to become a patch programmer. These seem 
like things best taken care of by include files and macros.
Now, something like an L-system object would be a different matter...it 
would still be quite flexible but would also parse much faster and 
probably consume less memory. The syntax would be a little hard to 
define, but the results would be worth it. And maybe a couple 
specialized patterns for making types of clouds and smoke with 
media...and maybe a partice system object.


> Good point(s). What I also fear is that if the programming language
> is extended in POV-Ray to include OO programming, for () loops, and
> all of the other programming suggestions that have been addressed
> in this thread, is what is going to happen when some non programming
> literate POV-User comes to the news groups seeking help and some
> programmer type gives them an example in the form of these new
> features ? The programmer types (and there a lot of them here in the
> groups that answer questions on a regular basis) will quickly adopt
> the attitude that everyone thinks like them and give examples in
> their language style of choice, while the real truth of the matter
> is that they could express themselves in a way that the people
> seeking help will not understand a word they are saying.

Do you really think the #for() loop would be harder to understand than a 
#while() loop? I think it would be easier to understand, at least, I 
found it easiest to understand and use when I was learning programming. 
(in Tandy and Commodore BASIC, yuck)
And why all the paranoia about object-oriented features? What does a POV 
script do? It manipulates *objects*. The object oriented features would 
only make this simpler. 500 pages? Try 5 pages, for the in depth 
description including examples. I'm not talking about inheritance, that 
wouldn't be necessary. I'm talking about the ability to have objects 
have accessible data(like MyCamera.location) and to attach variables and 
macros to objects.


> I would probably not use the new version if it became to hard to
> learn. This would restrict me to using the older versions of the
> program and I would miss out on new features.

Few of the feature requests I have seen would cause problems with 
backward compatability...

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

In article <38CA2519.7A4AFCB5@pacbell.net>, lin### [at] povrayorg 
wrote:

> I think you would be surprised to learn I had more problems thinking 
> in terms of 3D than I did learning POV's scripting language.

Hmm, my biggest problem was remembering all the keywords. :-)
I still can't remember off hand whether no_shadow or shadowless is used 
for an object...the thinking in 3D was actually the easiest part for me.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

In article <38ca2675@news.povray.org>, "Bob Hughes" 
<per### [at] aolcom?subject=PoV-News:> wrote:

> I had to wonder about your viewpoint on this for a moment but my 
> sentiments lean toward the hashmark (#) as being one of the things 
> that shows the person, not the parser alone (however that works), 
> where each of those special keywords are.

On the other hand, newbies might be scared away by a file full of 
mysterious commands with hash marks in front of them. :-)
Remember that the reason you use them as visual cues is that you are 
familiar with the language.


> But what may be getting overlooked is how POV has a programmer 
> language of sorts simply by being what it is: textual interface.  The 
> continuance of that into more features isn't the issue I'm sure, it's 
> the syntax that is the hub of this discussion.  By that reasoning it 
> should not ever be a hard-core programming language, instead it 
> should always be a common vocabulary most of all.

Well, it definitely shouldn't become a "hard-core programming language", 
since it's purpose is to describe scenes. But some of the features of 
more advanced languages would make the description of complex scenes 
including trees, plants, particle effects(like the Liquid Spray include) 
much easier. You wouldn't even have to understand them, you could just 
use include files written by others.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

In article <38CA3F4E.54F5C535@inapg.inra.fr>, Gilles Tran 
<tra### [at] inapginrafr> wrote:

> My own ventures in OO programming and other advanced programming 
> indicate that, though there's no discussion on the necessity of it 
> when it comes to programming efficiency, it also requires a *much 
> higher* level of abstract thinking. This may be natural to full-time 
> programmers, but for many people (including me) these ways of 
> thinking are extraordinary hard, if not impossible, to grasp. Many of 
> the concepts discussed in this thread (or in the programmers' wish 
> lists) are simply out of my intellectual reach.

I think you are getting scared off by the "inheritance" features of most 
object-oriented languages. They are the main source of complexity in 
programming languages, and I don't think they would be necessary or 
useful in POV. What I am talking about(and what I think most other 
people who want OO features are talking about) is adding the ability to 
bind macros and variables to objects, and access the attributes of the 
object. Which seems more intuitive:
#declare MyObject = object {MyObject translate y*3}
or
MyObject.Move(y*3);

You could have a separate Move() macro for a specific object which would 
do things like change the color depending on the distance moved. (like 
in steam dispersing or fire turning into smoke) The code would be much 
less complex, and easier to understand. Copies of the object would have 
the same macros and copies of the variables, but that would be the only 
inheritance-like feature, and is not difficult to understand.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

Chris Huff wrote:

> I am not sure if some of these things, like cloud objects, fur, trees,
> etc, would be a good language feature. It would be faster parsing, but
> that is about it. It would be more difficult to modify, if you want to
> customize it you would have to become a patch programmer. These seem
> like things best taken care of by include files and macros.

Well we have features like sky_sphere, rainbow, background, and
fog which are limited in scope but are still included with the
program and serve a purpose. Even limited functionality is better
than no functionality when you have no idea how to code it yourself.
Not everyone who uses POV-Ray has an internet connect nor do they
visit these groups. Many find the program on shareware CD's that
do not have a collection of the include files that we take for
granted. Some of these features like you mentioned can be better
handled and optimized internaly. Have you ever tried Gilles tree
macro with a recursion level over 7 ? MAN! it takes forever to parse.

> Now, something like an L-system object would be a different matter...it
> would still be quite flexible but would also parse much faster and
> probably consume less memory.

And as much material as is available on L-Systems I am surprised a
patch hasn't been presented.

 
> > Good point(s). What I also fear is that if the programming language
> > is extended in POV-Ray to include OO programming, for () loops, and
> > all of the other programming suggestions that have been addressed
> > in this thread, is what is going to happen when some non programming
> > literate POV-User comes to the news groups seeking help and some
> > programmer type gives them an example in the form of these new
> > features ? The programmer types (and there a lot of them here in the
> > groups that answer questions on a regular basis) will quickly adopt
> > the attitude that everyone thinks like them and give examples in
> > their language style of choice, while the real truth of the matter
> > is that they could express themselves in a way that the people
> > seeking help will not understand a word they are saying.
> 
> Do you really think the #for() loop would be harder to understand than a
> #while() loop? I think it would be easier to understand, at least, I
> found it easiest to understand and use when I was learning programming.
> (in Tandy and Commodore BASIC, yuck)

As I mentioned to Mr. Hubert what is easy for you is not always going
to be easy for everyone. Years ago I used for() loops and have completely
forgotten how to use them. AS time goes by I remember and miss them
less.

> And why all the paranoia about object-oriented features? What does a POV
> script do? It manipulates *objects*. The object oriented features would
> only make this simpler. 500 pages? Try 5 pages, for the in depth
> description including examples. I'm not talking about inheritance, that
> wouldn't be necessary. I'm talking about the ability to have objects
> have accessible data(like MyCamera.location) and to attach variables and
> macros to objects.

And I keep seeing the same tired example. What else can you do with OO
that you can't already do in POV-Ray ? How many of the current users will
be able to understand a scene example from you using OO if you provided
one ? Even other programmers balk at the idea. Shouldn't the non programmer
user also worry ?
 
> > I would probably not use the new version if it became to hard to
> > learn. This would restrict me to using the older versions of the
> > program and I would miss out on new features.
> 
> Few of the feature requests I have seen would cause problems with
> backward compatability...

Ok, you maintain backward compatibility but how much bloat will it
add ? Will POV-Ray run faster ?

-- 
Ken Tyler -  1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

Chris Huff wrote:

> object. Which seems more intuitive:
> #declare MyObject = object {MyObject translate y*3}
> or
> MyObject.Move(y*3);

To me the first example is more intuitive. Where does Move come from ?

I don't like the idea that I would have to make a macro just to move an
object. Seems like extra work to me. Point still not conceded.

-- 
Ken Tyler -  1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

In article <38CA6435.A9A33FAA@pacbell.net>, lin### [at] povrayorg 
wrote:

> Well we have features like sky_sphere, rainbow, background, and
> fog which are limited in scope but are still included with the
> program and serve a purpose. Even limited functionality is better
> than no functionality when you have no idea how to code it yourself.

I don't see how they compare...clouds can be done with the sky_sphere, 
if that is the type of thing you are talking about. If you are talking 
about actual clouds, instead of a background effect, I don't see how 
this could possibly be done and be easier or faster than media clouds. 
Are you talking about a kind of sky_sphere with a special cloud 
generating algorithm for it's pigment? Then why not just add a new kind 
of pigment and use the current sky_sphere? Less features to learn and 
keywords to memorize...and you would be able to use it with other things.

Clouds are just something better put in the scene file than in hard to 
change source code. There are even include files that come with the 
program that do clouds...fog, background, rainbow, and sky_sphere would 
also be bad things to hard-code, since they need to be changed 
frequently. Maybe you want something like a "cloud box", which would be 
an automated way of putting a layer of media in the sky?


> Not everyone who uses POV-Ray has an internet connect nor do they
> visit these groups. Many find the program on shareware CD's that
> do not have a collection of the include files that we take for
> granted. Some of these features like you mentioned can be better
> handled and optimized internaly. Have you ever tried Gilles tree
> macro with a recursion level over 7 ? MAN! it takes forever to parse.

Actually, I haven't. But I have tried my own tree macros with recursions 
of over 20. And some of my particle simulations have had extremely long 
parse times.
Why would it have to be included in the program itself? It could be part 
of the standard includes. If it was added to the program itself, it 
would have to be written so it is flexible enough to be used in 
different kinds of scenes.


> > Now, something like an L-system object would be a different matter...it
> > would still be quite flexible but would also parse much faster and
> > probably consume less memory.
> 
> And as much material as is available on L-Systems I am surprised a
> patch hasn't been presented.

As am I. I think the main reason is the parser for the L-System script, 
they would certainly be a nice feature. And even if they were hard to 
control, a few starter objects could be put in the include files.


> And I keep seeing the same tired example. What else can you do with 
> OO that you can't already do in POV-Ray ? How many of the current 
> users will be able to understand a scene example from you using OO if 
> you provided one ? Even other programmers balk at the idea. Shouldn't 
> the non programmer user also worry ?

You can do this in POV-Ray now, true...but it is sloppy and hard to 
read. It is also prone to producing bugs if you modify the scene later.
POV is object oriented now. This would just remove a few limitations on 
it.
And I think that the only reason for a scene example with a hard to 
understand OO portion would be to demonstrate that hard to understand OO 
portion. And really, if you are already using POV, you shouldn't have 
any problem understanding these features.


> Ok, you maintain backward compatibility but how much bloat will it
> add ? Will POV-Ray run faster ?

Current scenes shouldn't parse noticeably slower, and if the parser is 
significantly rewritten in the process of adding these features, they 
might actually parse faster...render speed would not be affected at all.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

In article <38CA66D7.9E1F957C@pacbell.net>, lin### [at] povrayorg 
wrote:

> To me the first example is more intuitive. Where does Move come from ?
> 
> I don't like the idea that I would have to make a macro just to move an
> object. Seems like extra work to me. Point still not conceded.

Who said the macro was required? You could still redeclare and translate 
it if you wanted, you just would have a harder time keeping track of 
things.
Say you have a long string of objects that are linked together. You move 
one, and it affects all the others. You can calculate the positions and 
transformations for all of them(maybe enclosing the whole thing in a 
macro), or you can have each one be manipulated by a macro and only call 
the base macro. A macro and variable would be attached by doing 
something like this:
object {
    #local DistanceMoved = 0;
    #macro Move(Direction)
        translate Direction
        #local DistanceMoved = DistanceMoved + vlength(Direction);
        // or this... :-)
        #local DistanceMoved += vlength(Direction);
    #end
}

To do something like this without OO features, you would have to make a 
special macro and set of variables for each object, separated only by a 
unique name.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

Chris Huff wrote:
> 
> In article <38CA6435.A9A33FAA@pacbell.net>, lin### [at] povrayorg
> wrote:
> 
> > Well we have features like sky_sphere, rainbow, background, and
> > fog which are limited in scope but are still included with the
> > program and serve a purpose. Even limited functionality is better
> > than no functionality when you have no idea how to code it yourself.
> 
> I don't see how they compare...clouds can be done with the sky_sphere,
> if that is the type of thing you are talking about. If you are talking
> about actual clouds, instead of a background effect, I don't see how
> this could possibly be done and be easier or faster than media clouds.
> Are you talking about a kind of sky_sphere with a special cloud
> generating algorithm for it's pigment? Then why not just add a new kind
> of pigment and use the current sky_sphere? Less features to learn and
> keywords to memorize...and you would be able to use it with other things.
> 
> Clouds are just something better put in the scene file than in hard to
> change source code. There are even include files that come with the
> program that do clouds...fog, background, rainbow, and sky_sphere would
> also be bad things to hard-code, since they need to be changed
> frequently. Maybe you want something like a "cloud box", which would be
> an automated way of putting a layer of media in the sky?

I think you missed my point. We already HAVE sky_spheres, rainbows and
fog but their usefulness is limited. They are however features of the
program that are used and appreciated. What Gilles was talking about
in terms of clouds is a feature that is present in Terragen that produces
some absolutely awesome clouds. It uses a method unknown to me, that not
only render quickly but are configurable, easy to use, and are absolutely
believable. I would hazard a guess that they are similar to the sky_sphere
feature we have now but with enhancements (Gilles ?).

If you are not familiar with Terragen stop by their web page and look
at the image gallery - http://www.planetside.co.uk/

> > Not everyone who uses POV-Ray has an internet connect nor do they
> > visit these groups. Many find the program on shareware CD's that
> > do not have a collection of the include files that we take for
> > granted. Some of these features like you mentioned can be better
> > handled and optimized internaly. Have you ever tried Gilles tree
> > macro with a recursion level over 7 ? MAN! it takes forever to parse.
> 
> Actually, I haven't. But I have tried my own tree macros with recursions
> of over 20. And some of my particle simulations have had extremely long
> parse times.
> Why would it have to be included in the program itself? It could be part
> of the standard includes. If it was added to the program itself, it
> would have to be written so it is flexible enough to be used in
> different kinds of scenes.

  Lets say for a moment that some brilliant programmer has the patience
and drive to write a patch that would add a tree object to the program.
Even if the tree patch couldn't do every tree on earth do you really
think that there is not one person out there using POV-Ray that wouldn't
try using this feature at least once ?

 Gilles tree macro only requires that you make a handful of declarations
and fill in the space for initializing the macro itself. The diversity
available with the macro itself is incredible because it was well thought
out and is easy to use. Why could something like this not be included with
the program ? Why would it be undesirable to have a feature like this that
ran faster internally instead of waiting 20 minutes for the code to parse ?

I understand the desire to do it all yourself in native Pov but do you
understand the desire of some who don't want to hassle with it or simply
are not intellectually capable of doing so ?


 I see four maybe five major areas that POV-Ray is weak in that still
need to be improved upon.

An easy method of mechanically roughening/smoothing a surface - displacement
mapping and subdivision.

Clouds and Smoke - yeah we have seen media do it but it is far from
easy, it is not intuitive, and the render time is still expensive
even with Nathan's enhancements. From what I have seen so far only
the *expert* users of the program come close to achieving believable
results with media while everyone else is still going "huh ?".

Irregular shapes creation - Isosurfaces sure - if you are some kind
of mathematical genius.

Some form of organic modelling system - a tree generator, L-Systems,
whatever.

While I am drifting off topic a bit here there is a reason for it.
You say add better language abilities to the program to achieve these
things. I say improve the program by adding these things to it. I
think this is the point that Gilles was trying to make. This is the
vital difference between a programmer mentality and a user mentality.
Why should I have to learn even more POV-Ray scripting options like
OO and for() loops when the program is supposed to be doing the
thinking for me ? The program is supposed to speed up scene development
and image creation not acting as a programmers development environment.
Let us not lose sight of this.

> > And I keep seeing the same tired example. What else can you do with
> > OO that you can't already do in POV-Ray ? How many of the current
> > users will be able to understand a scene example from you using OO if
> > you provided one ? Even other programmers balk at the idea. Shouldn't
> > the non programmer user also worry ?
> 
> You can do this in POV-Ray now, true...but it is sloppy and hard to
> read. It is also prone to producing bugs if you modify the scene later.
> POV is object oriented now. This would just remove a few limitations on
> it.
> And I think that the only reason for a scene example with a hard to
> understand OO portion would be to demonstrate that hard to understand OO
> portion. And really, if you are already using POV, you shouldn't have
> any problem understanding these features.

  This will remain to be seen. I do hope that once a patch is written
for OO that it is given a fair treatment in the patch community before
it is added to the official version. I am going to maintain a "wait and
see" attitude until then.


-- 
Ken Tyler -  1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

Ken wrote:

> You say add better language abilities to the program to achieve these
> things. I say improve the program by adding these things to it. I
> think this is the point that Gilles was trying to make. This is the
> vital difference between a programmer mentality and a user mentality.
> Why should I have to learn even more POV-Ray scripting options like
> OO and for() loops when the program is supposed to be doing the
> thinking for me ? The program is supposed to speed up scene development
> and image creation not acting as a programmers development environment.
> Let us not lose sight of this.

Very good points, Ken.

If you look at Terragen or Vue d'Esprit, very realistic cloud effects can be
done
very fast and very effectively. I don't have a clue about how it's done but we
know it's possible. Actually these were just examples of what, as a pov user,
I would *really* need, because my goal is to make images, and not to code them.
Commercial programmes offer many bells and whistles of this kind because
they have a user base that requires them (and pays for them). In fact, all
of the features I quoted are taken for granted in one or another commercial
application, in the programme itself or in its plugins.
You can have a look at the vegetation engine in Vue d'Esprit for another
example.
http://www.e-onsoftware.com/Gallery/Day.php3?Index=0

Remember the AWESOME ROLLEX story ? The ocean pic was made with a plugin
for Max/Maya/Lightwave/Softimage. People got very excited because
it looked so great in pov, but, as far as I know, nobody ever got close
to that quality in pov.
You can see the ocean original here http://www.areteis.com/gallery/otw.jpg

I'm not asking for anything, just want to make clear that there are lots of
areas to
investigate for people with programming talent, and many of them have to
do with pov ability to render images. And this, for me would be much more
important that any syntax streamlining.

Most of us can live with a=a+1 instead of a +=1, but sorely miss being able
to render a good sky, or a good ocean, or a good fur,  at an acceptable
coding/computing price.

I'll add something : many aspects of programming that may appear sloppy to
the professional programmer are often very much appreciated by non-programmers.
I don't like to declare variables. I don't like variables having "types". I
don't like
shortcut operators. I may prefer verbose and redundant statements to clean,
streamlined ones if the latter seem obfuscated to me. And generally speaking I
tend to get lost with complex, abstract constructs which may be heaven-sent for
people with powerful brains, but not for me. Why is that ? Because, as a user,
I like to restrict my coding to its scene-oriented questions. I don't want the
code
to be a burden (for instance by multiplying the abstraction levels). I don't
want
obscure messages that will tell me that something was not instanciated (uh?)
or that some class wasn't defined. Even a "type mismatch" error should be
superfluous.
In database management, we know for instance that there is a trade-off between
the conceptual purity of the database design and its usability. We
can get carried away by designing databases that are both formally perfect and
unusable. As I previously said, I think that the very (relative) clumsiness
of the pov syntax is also one reason for its present success in the
non-programming world.

G.



>
> > > And I keep seeing the same tired example. What else can you do with
> > > OO that you can't already do in POV-Ray ? How many of the current
> > > users will be able to understand a scene example from you using OO if
> > > you provided one ? Even other programmers balk at the idea. Shouldn't
> > > the non programmer user also worry ?
> >
> > You can do this in POV-Ray now, true...but it is sloppy and hard to
> > read. It is also prone to producing bugs if you modify the scene later.
> > POV is object oriented now. This would just remove a few limitations on
> > it.
> > And I think that the only reason for a scene example with a hard to
> > understand OO portion would be to demonstrate that hard to understand OO
> > portion. And really, if you are already using POV, you shouldn't have
> > any problem understanding these features.
>
>   This will remain to be seen. I do hope that once a patch is written
> for OO that it is given a fair treatment in the patch community before
> it is added to the official version. I am going to maintain a "wait and
> see" attitude until then.
>
> --
> Ken Tyler -  1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
> http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

Chris Huff wrote:

> Say you have a long string of objects that are linked together. You move
> one, and it affects all the others.

<snip>

> To do something like this without OO features, you would have to make a
> special macro and set of variables for each object, separated only by a
> unique name.

Or to do this you can use a graphical modelling environment which is much
better suited to this task than a text based scripting language is for example
Moray with it's new animation plugin and it's IK abilities.

-- 
Ken Tyler -  1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

In article <38CA8F7A.D6CC37D6@pacbell.net>, lin### [at] povrayorg 
wrote:

> > To do something like this without OO features, you would have to make a
> > special macro and set of variables for each object, separated only by a
> > unique name.
> 
> Or to do this you can use a graphical modelling environment which is 
> much better suited to this task than a text based scripting language 
> is for example Moray with it's new animation plugin and it's IK 
> abilities.

Ken, Ken, Ken. You should know better than that. I will just skip the 
comment about using a modeller instead of hand coding and get to the 
point: this was just an *example*. Even if your solution was valid for 
all platforms and all cases objects need to be linked together, this 
isn't the only reason for object oriented features. If it was, I would 
be suggesting a way to link objects together instead.(which may actually 
not be such a bad idea...)
Also, wouldn't a tree generator also be better implemented in a 
graphical modelling environment? :-)

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

Chris Huff wrote:

> Ken, Ken, Ken. You should know better than that.

The Devil made me do it...

> Also, wouldn't a tree generator also be better implemented in a
> graphical modelling environment? :-)

Absolutely not. I have no patience for positioning 30,000 objects
by hand in a GUI modelling program.

-- 
Ken Tyler -  1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

In article <38CA8CFB.D837BDD2@inapg.inra.fr>, Gilles Tran 
<tra### [at] inapginrafr> wrote:

> If you look at Terragen or Vue d'Esprit, very realistic cloud effects 
> can be done very fast and very effectively. I don't have a clue about 
> how it's done but we know it's possible. Actually these were just 
> examples of what, as a pov user, I would *really* need, because my 
> goal is to make images, and not to code them.
> Commercial programmes offer many bells and whistles of this kind 
> because they have a user base that requires them (and pays for them). 
> In fact, all of the features I quoted are taken for granted in one or 
> another commercial application, in the programme itself or in its 
> plugins.
> You can have a look at the vegetation engine in Vue d'Esprit for another
> example.
> http://www.e-onsoftware.com/Gallery/Day.php3?Index=0

Actually, the first thing I noticed was the stone texture...that is 
quite nice. :-)
Are Terragen and Vue d'Esprit raytracers? Some effects like clouds and 
complex plants are easier to implement and faster to render in 
scanline-type renderers, they may not be applicable to POV-Ray.
Would you be satasfied with a special "cloud pigment" that you can apply 
to a sky_sphere?


> Remember the AWESOME ROLLEX story ? The ocean pic was made with a plugin
> for Max/Maya/Lightwave/Softimage. People got very excited because
> it looked so great in pov, but, as far as I know, nobody ever got close
> to that quality in pov.
> You can see the ocean original here 
> http://www.areteis.com/gallery/otw.jpg

I remember that, although as I recall, it was spelled "AWSOME ROLLEX". 
:-)
I have seen better water in POV, although I can't remember exactly 
where... This looks "frozen" to me, and kind of like plastic, probably 
because there aren't any clouds to reflect and the highlights seem 
constant all the way to the horizon. A simple isosurface using a 
wrinkles pigment scaled larger in one direction for displacement(or a 
*huge* resolution height field) would work well.


> I'm not asking for anything, just want to make clear that there are 
> lots of areas to investigate for people with programming talent, and 
> many of them have to do with pov ability to render images. And this, 
> for me would be much more important that any syntax streamlining.
> Most of us can live with a=a+1 instead of a +=1, but sorely miss 
> being able to render a good sky, or a good ocean, or a good fur,  at 
> an acceptable coding/computing price.

If you have a few features to request, then go ahead and request them!
One of the reasons features are not added is that nobody says they want 
them. You way there are other things you would consider more important 
than syntax streamlining, what are they? You mention clouds, oceans, 
fur, etc but didn't really give much information on what you want to see.
(You want clouds? What kind? A texture type, a background effect, an 
object type...?
You want oceans? What kind? A texture type, a height-field feature, a 
separate object...? Fur is pretty obvious, the main reason it hasn't 
been done is probably the difficulty of implementing it in a raytracer.)

With things like angle-dependant reflection and isosurfaces, good oceans 
are possible. Good skies are possible now, and quite fast if you use 
pigments to do them. Fur is possible using media, although a bit 
difficult. 
Do you want some kind of starter scenes with the basic code in place? I 
really don't think an "ocean" primitive is a good idea...but if you can 
give a good reason for it's existance and some example syntax someone 
might code one.


> I'll add something : many aspects of programming that may appear 
> sloppy to the professional programmer are often very much appreciated 
> by non-programmers.

Like what? I really don't know what you mean...
Do you want a goto statement or something?


> I don't like to declare variables. I don't like variables having "types". 
> I don't like shortcut operators. I may prefer verbose and redundant 
> statements to clean, streamlined ones if the latter seem obfuscated 
> to me. And generally speaking I tend to get lost with complex, 
> abstract constructs which may be heaven-sent for people with powerful 
> brains, but not for me. Why is that ? Because, as a user, I like to 
> restrict my coding to its scene-oriented questions. I don't want the 
> code to be a burden (for instance by multiplying the abstraction 
> levels). I don't want obscure messages that will tell me that 
> something was not instanciated (uh?) or that some class wasn't 
> defined. Even a "type mismatch" error should be superfluous.

I have never seen either of those errors with POV, and haven't seen any 
suggestions which would cause them except for the requested addition of 
types. And even then, the suggestion was for a way to override the 
normal typing system, you could continue to write the way you do and 
never see any type-checking messages.
Not even more object oriented features would require adding types. It's 
just attaching variables and macros to shapes.


> In database management, we know for instance that there is a 
> trade-off between the conceptual purity of the database design and 
> its usability. We can get carried away by designing databases that 
> are both formally perfect and unusable. As I previously said, I think 
> that the very (relative) clumsiness of the pov syntax is also one 
> reason for its present success in the non-programming world.

I am not so sure about this...many of these things are not being 
introduced to add "conceptual purity", but to make things easier on 
people writing complex includes.


There is another alternative which is being discussed in 
povray.off-topic which I am surprised hasn't been mentioned here: making 
a new language, starting from the basics and ensuring a clean design, 
probably similar to C(I suggested POV-CSDL, for POV C-like Scene 
Description Language), and using a translator program to convert files 
written in it to POV-Script files to be rendered. Programmer type people 
could make their includes in this environment and distribute both the 
POV-CSDL and the POV-Script files. That way, non programmers wouldn't be 
complaining about features being added that they can't/won't use, and 
programmers would have a more powerful and flexible environment for 
scene and include development. I have actually considered writing a 
program like this, the main thing stopping me is that I know virtually 
nothing about writing parsers. :-(

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message