Dave Dunn wrote:
> It is interesting that so many people care more about what the program is
doing
> internally than what the users do with the program. I agree, and have
said, that
> from an internal (program-level) standpoint all the above is true. But, as
an
> end-user, I would like to know that the program will anticipate my belief
that,
> if I can translate x*3, and rotate x*3, that I should be able to scale x*3
> without generating an error or a warning. This is how many people work in
> POV-Ray, and the indigestion that it causes the source code is of little
> concern. I have spent the last eight years as the AOL POV specialist,
trying to
> convince new users that POV-Ray is not that hard to use, yet it seems that
there
> are some folks who, out of concern for the purity of the internal working
of the
> code, would make it even harder. But, since we disagree, let's just leave
it at
> that. I apologige for letting this discussion get this far.

Thing is that x is <1,0,0> always and everywhere. You agree that 'scale
<3,0,0>' can't be correct: 'scale 3*x' is just the same thing. You want to
give x another meaning with scale but x will just remain what it is now:
<1,0,0>. It's not internally turned into <1,0,0>, x is by definition
<1,0,0>, it's just a shortcut, so you're simply EXPLICITLY telling POV
"scale <3,0,0>", which can't be correct. Methinks you didn't get this point:
I personally don't care what POV does internally, but if I say 'box' I don't
want the parser to read 'sphere'. Thus if I write 'x' I mean it, i.e.
<1,0,0>. I don't want POV to turn my x into x +<0,1,1>, why? So, I find the
present behaviour acceptable: if you like to make it the wrong way (because
IT IS the wrong way) POV will help you, but nothing can prevent it to tell
you that you're making it the wrong way.

--
Jonathan.

Post a reply to this message