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

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