 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
David Fontaine <dav### [at] faricy net> wrote:
: perhaps POV should have (or does it?) an
: configurable option to treat warnings as errors and stop parsing, like
: in many compilers.
Yes, I like the idea of having a '-pedantic' option which converts warnings
to errors.
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
David Fontaine wrote:
> Besides, look at it this way:
> scale <1,1,1> = [1 0 0 0]
> [0 1 0 0]
> [0 0 1 0]
> [0 0 0 1]
> as do rotate <0,0,0> and translate <0,0,0>; it is the *identity*.
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.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sun, 02 Dec 2001 11:07:13 -0500, Dave Dunn wrote:
> 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.
The problem is that believing that scale x*3 does something different than
it really does gives you an artificial barrier to overcome later, when you
discover that that's not really what it does.
Personally, I think the current behavior is perfect: it allows you to use
scale x*3 as if it works that way, but it reminds you each time you do that
that's not really what it's doing and we're just letting you get away with
it.
--
#macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z a-z)R(a
-z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F T)merge{
P(z+a)P(z-a)R(-z-z-x a)pigment{rgbf 1}hollow interior{media{emission 3-T}}}#end
Z(-x-x.2x)camera{location z*-10rotate x*90normal{bumps.02scale.05}}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker wrote:
>Personally, I think the current behavior is perfect: it allows you to use scale x*3
as >if it works that way, but it reminds you each time you do that that's not really
what >it's doing and we're just letting you get away with it.
I will accept that, with the final obeservation that, by virtue of the fact that it
is changing those 0s to 1s, it kind of is doing that. My point was, it should just
do that, in this specific case, without letting you know. But I can see your point,
and as I have said earlier, I realize that I have been a bit obstinate in pushing
this point, and will not comment further.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Dave Dunn <poi### [at] aolcom> wrote:
: 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.
The problem with your thinking is that you talk as if the "x*3" was a
"shortcut" property of "translate" or "rotate", when it actually isn't.
"translate x*3" just happens to work because "x*3" is defined to expand to
"<3,0,0>", which is ok for translate. However, the "x*3" has nothing to do
with the translate command itself. Thus you can't expect the same trick to
work with other commands which require a different syntax to work.
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
JRG wrote:
> >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.
I have been using POV-Ray for almost nine years. I certainly know the definition
of x (or y or z for that matter). My remarks, which have universally been taken
as signs of ignorance, concerned the ergonomic fact that, for the special case
of scale, since POV *does* change the 0s to 1s (like it or not it does this),
that the warning for this case alone should not be given. The rationale for this
is that it is simply *as an end-user* easier to type scale x*.2 than scale
<.2,1,1>, when the internal parser is happily converting those offending 0s to
1s anyay. As a prograamer you may be horrified that I want the program to make
it easier for me to do something, but as a user, I want it as efficient as I can
get it.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Dave Dunn <poi### [at] aolcom> wrote:
: As a prograamer you may be horrified that I want the program to make
: it easier for me to do something, but as a user, I want it as efficient as I can
: get it.
Suppose that you have a #while-loop where you are creating copies of the
same object scaled thinner and thinner in one axis. However, you make a small
mistake and forget that scaling by 0 is not possible, and you have one of
those copies scaled by 0 in that axis.
So what you get is a series of objects scaled thinner and thinner and
thinner and... What? One of the objects is not scaled! What happened here?
Is there a bug in POV-Ray?
Now, if you look at the message window and see the warning, you immediately
realize that "oops! true, I forgot to take into account the scale-by-0 case".
However, if there is no warning, you may not see what is wrong there!
In my opinion it shouldn't even be a warning, but a plain error. It would
stop this kind of mistakes immediately.
Understand better now?
--
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Dave Dunn wrote:
> I have been using POV-Ray for almost nine years. I certainly know the
definition
> of x (or y or z for that matter). My remarks, which have universally been
taken
> as signs of ignorance, concerned the ergonomic fact that, for the special
case
> of scale, since POV *does* change the 0s to 1s (like it or not it does
this),
> that the warning for this case alone should not be given. The rationale
for this
> is that it is simply *as an end-user* easier to type scale x*.2 than
scale
> <.2,1,1>, when the internal parser is happily converting those offending
0s to
> 1s anyay. As a prograamer you may be horrified that I want the program to
make
> it easier for me to do something, but as a user, I want it as efficient as
I can
> get it.
You have to live with the fact that many users want POV to tell them if
something is going wrong in this direction (when designing transformation
macros for example). I know that you know what x, y and z mean, I just
wanted to focus on the fact that they work this way everywhere, and it would
be quite confusing if they had to work differently in different cases. As
Warp pointed out, the fact that those shortcuts work fine with some
transformations does not mean that they have to work fine everywhere.
Suppose you have a macro that (through a matrix) scale an object something
like <0.00000000000001,2.5,0.000000000000000001>. Suppose now that those
tiny numbers (due to inside approximation) are turned to 0. POV-Ray will
turn them to 1 and will warn you, so that you can undertand what's going on
and adapt your macro to those inside limits.
I understand what you mean, but I think that the most important thing for
the user it consistency. If we start to put here and there exceptions to the
rules, things won't be easier, but harder.
--
Jonathan.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Ron Parker" <ron### [at] povrayorg> wrote in message
news:slr### [at] fwicom...
> On Sat, 01 Dec 2001 12:47:00 -0500, Dave Dunn wrote:
> > special case, whose values are initialized at <1,1,1>, and if you want
to scale
> > by any of the axes alone, the other two axes should remain at the value
of 1.
>
> Except that there's no way of indicating that you want to scale any of the
> axes alone.
Sure there is. If you want to double the scale in the X direction, use
scale 1+x
Easy enough, though it might confuse beginners :)
I agree, though, that POV's current behavior is perfect - it works, but
complains that you're mistreating it.
...Chambers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
