 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hello! How can I make a disc which is not infinite flat?!
Martin
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Do you mean something like this?
sphere{0,1 scale y*.1}
or maybe this?
cylinder {y,-y,1 scale y*.1}
--
- Nekar
http://nekar_xenos.tripod.com/metanoia/
"Martin Thoma" <mar### [at] radiok2r de> wrote in message
news:3C0629CF.B3EABB60@radiok2r.de...
> Hello! How can I make a disc which is not infinite flat?!
>
> Martin
>
>
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.298 / Virus Database: 161 - Release Date: 2001/11/13
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nekar Xenos wrote:
>
> cylinder {y,-y,1 scale y*.1}
That should be scale <1,.1,1>
--
David Fontaine <dav### [at] faricynet> ICQ 55354965
My raytracing gallery: http://davidf.faricy.net/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"David Fontaine" <dav### [at] faricynet> wrote in message
news:3C06C487.19BEFCB2@faricy.net...
> Nekar Xenos wrote:
> >
> > cylinder {y,-y,1 scale y*.1}
>
> That should be scale <1,.1,1>
>
I didn't know there's a difference. Can you please explain that to me?
Thanks,
--
- Nekar
http://nekar_xenos.tripod.com/metanoia/
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.298 / Virus Database: 161 - Release Date: 2001/11/13
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
y*.1 is equivalent to <0,.1,0>. You can't scale an object by zero in any
direction - it's like squishing it to zero thickness, and there are
mathematical reasons why the concept doesn't work (it relates to division by
zero). You'll notice that when you use something like that, POV-Ray gives
you a warning saying that you can't scale by zero, and it's replacing the
zeros with ones. That's usually the intended behavior, as you just
demonstrated. I usually don't worry about the warnings, since it's pretty
obvious what my intent is when I say scale y*.1, but if you want to be
really correct about it, use scale <1,.1,1> or scale y*.1 +x+z.
--
- Slime
[ http://www.slimeland.com/ ]
[ http://www.slimeland.com/images/ ]
"Nekar Xenos" <j-p### [at] citywalkcoza> wrote in message
news:3c072bf2@news.povray.org...
>
> "David Fontaine" <dav### [at] faricynet> wrote in message
> news:3C06C487.19BEFCB2@faricy.net...
> > Nekar Xenos wrote:
> > >
> > > cylinder {y,-y,1 scale y*.1}
> >
> > That should be scale <1,.1,1>
> >
> I didn't know there's a difference. Can you please explain that to me?
>
> Thanks,
> --
> - Nekar
>
> http://nekar_xenos.tripod.com/metanoia/
>
>
>
> ---
> Outgoing mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.298 / Virus Database: 161 - Release Date: 2001/11/13
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Slime" <noo### [at] hotmailcom> wrote in message
news:3c07373d$1@news.povray.org...
> y*.1 is equivalent to <0,.1,0>. You can't scale an object by zero in any
> direction - it's like squishing it to zero thickness, and there are
> mathematical reasons why the concept doesn't work (it relates to division by
> zero). You'll notice that when you use something like that, POV-Ray gives
> you a warning saying that you can't scale by zero, and it's replacing the
> zeros with ones. That's usually the intended behavior, as you just
> demonstrated. I usually don't worry about the warnings, since it's pretty
> obvious what my intent is when I say scale y*.1, but if you want to be
> really correct about it, use scale <1,.1,1> or scale y*.1 +x+z.
>
Thanks. I've always wondered about all those warnings... ;)
--
- Nekar
http://nekar_xenos.tripod.com/metanoia/
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.298 / Virus Database: 161 - Release Date: 2001/11/13
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Slime <noo### [at] hotmailcom> wrote:
: y*.1 is equivalent to <0,.1,0>. You can't scale an object by zero in any
: direction - it's like squishing it to zero thickness, and there are
: mathematical reasons why the concept doesn't work (it relates to division by
: zero).
The exact reason is that POV-Ray doesn't actually transform the object at
all, but it instead transforms the ray with the inverse transformation when
the ray-object intersection is tested.
The inverse transformation of scale <0, .1, 0> is scale <1/0, 1/.1, 1/0>.
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message news:3c078c70@news.povray.org...
What are the chances of having this warning removed?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 30 Nov 2001 16:50:05 -0000, "Tom Melly" <tom### [at] tomandlucouk> wrote:
> What are the chances of having this warning removed?
Personally I prefer when software inform me when he know better what shuld be
passed and change values. But if you don't like it you can check "-GW" ini
switch.
ABX
--
#declare _=function(a,b,x){((a^2)+(b^2))^.5-x}#default {pigment{color rgb 1}}
union{plane{y,-3}plane{-x,-3}finish{reflection 1 ambient 0}}isosurface{ //ABX
function{_(x-2,y,1)|_((x+y)*.7,z,.1)|_((x+y+2)*.7,z,.1)|_(x/2+y*.8+1.5,z,.1)}
contained_by{box{<0,-3,-.1>,<3,0,.1>}}translate z*15finish{ambient 1}}//POV35
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Tom Melly" wrote:
> What are the chances of having this warning removed?
100%. Use the command line setting -gw.
Seriously, I don't want it to be removed. I've encountered lots of cases
where the correction of the 0's to 1's were not desired. For example if I
have a matrix that due to an error scales the object by 0 in one direction.
If not I was warned it would be extremely difficult to find out what's going
on. It also happens often that a while loop or similar that scales an object
smaller and smaller reaches 0 due to a bug in the script, and then the
object is suddenly scaled by 1. I want to be warned about that.
Rune
--
3D images and anims, include files, tutorials and more:
Rune's World: http://rsj.mobilixnet.dk (updated Nov 5)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tom Melly <tom### [at] tomandlucouk> wrote:
: What are the chances of having this warning removed?
What should be done is that the warning is replaced with an error.
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> What should be done is that the warning is replaced with an error.
That's a bit extreme, isn't it? It is obviously easier, from a user's
standpoint, to type scale y*.1 than scale <1,.1,1>, and most of us do it
anyway, ignoring the warning. The fact that POV is internally groaning because
we tried to divide by zero should be immaterial to the user, who assumes by
scaling only one axis that the other ones will not be scaled by anything.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3C07F02B.A1CD5A65@aol.com> , Dave Dunn <poi### [at] aolcom>
wrote:
> That's a bit extreme, isn't it? It is obviously easier, from a user's
> standpoint, to type scale y*.1 than scale <1,.1,1>, and most of us do it
I think you got something wrong here! scale y*.1 is perfectly equivalent
with scale <1,.1,1> in POV-Ray and has nothing to do with what Warp is
talking about...
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 30 Nov 2001 22:01:49 +0100, Thorsten Froehlich wrote:
> In article <3C07F02B.A1CD5A65@aol.com> , Dave Dunn <poi### [at] aolcom>
> wrote:
>
>> That's a bit extreme, isn't it? It is obviously easier, from a user's
>> standpoint, to type scale y*.1 than scale <1,.1,1>, and most of us do it
>
> I think you got something wrong here! scale y*.1 is perfectly equivalent
> with scale <1,.1,1> in POV-Ray and has nothing to do with what Warp is
> talking about...
Actually, it's equivalent to scale <0,.1,0> (except that we change it to
<1,.1,1> and print a warning) and is in fact exactly what Warp is talking
about: he thinks the warning should be an error instead. Or at least it
appears so to me; perhaps he would like to clarify.
--
#local R=rgb 99;#local P=R-R;#local F=pigment{gradient x}box{0,1pigment{gradient
y pigment_map{[.5F pigment_map{[.3R][.3F color_map{[.15red 99][.15P]}rotate z*45
translate x]}]#local H=pigment{gradient y color_map{[.5P][.5R]}scale 1/3}[.5F
pigment_map{[.3R][.3H][.7H][.7R]}]}}}camera{location.5-3*z}//only my opinions
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
x, y and z are just *shortcuts* for <1,0,0> <0,1,0> and <0,0,1>
respectively. As you know vectors aren't used exclusively for
transformations (i.e. rotations, translations and scale), so they must work
the same way in any circumstance. I mean, if I write y, I mean <0,1,0> (what
otherwise?). So, since rotate, translate and scale need a vector, and since
x, y and z are those vectors I mentioned above and HAVE to work the same way
everywhere, if you write scale 2*x the parser HAS to read <2,0,0>. I
personally never used to scale individual axes, but think that those
warnings are just enough.
--
Jonathan.
"Dave Dunn" <poi### [at] aolcom> ha scritto nel messaggio
news:3C07F02B.A1CD5A65@aol.com...
>
>
> Warp wrote:
>
> > What should be done is that the warning is replaced with an error.
>
> That's a bit extreme, isn't it? It is obviously easier, from a user's
> standpoint, to type scale y*.1 than scale <1,.1,1>, and most of us do it
> anyway, ignoring the warning. The fact that POV is internally groaning
because
> we tried to divide by zero should be immaterial to the user, who assumes
by
> scaling only one axis that the other ones will not be scaled by anything.
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <slr### [at] fwicom> , Ron Parker
<ron### [at] povrayorg> wrote:
> Actually, it's equivalent to scale <0,.1,0> (except that we change it to
> <1,.1,1> and print a warning) and is in fact exactly what Warp is talking
> about: he thinks the warning should be an error instead. Or at least it
> appears so to me; perhaps he would like to clarify.
You are right. In fact I never knew that the syntax would cause a warning
in the first place as it (obviously) doesn't in translate or rotate i
assumed scale, also slightly different works the same. IMO, it should not be
a warning at all and just silently work...
Thorsten
____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde
Visit POV-Ray on the web: http://mac.povray.org
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thorsten Froehlich wrote:
> IMO, it should not be a warning at all and just silently work...
That was exactly my point. For once we agree ; }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker <ron### [at] povrayorg> wrote:
: Actually, it's equivalent to scale <0,.1,0> (except that we change it to
: <1,.1,1> and print a warning) and is in fact exactly what Warp is talking
: about: he thinks the warning should be an error instead. Or at least it
: appears so to me; perhaps he would like to clarify.
Exactly. As scaling by zero is illegal, then an error should be issued,
as with all illegal values.
Think about this:
camera { look_at 0 }
Having the camera location and look_at in the same point is illegal, and
thus an error is issued. POV-Ray doesn't (and shouldn't!) assume that
"oh, the user just mistyped this number, I'll convert it to 'look_at z' for
him".
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Exactly. As scaling by zero is illegal, then an error should be issued,
> as with all illegal values.
I am perfectly happy with the current behavior and with respect choose
to disagree with your suggestion.
> Think about this:
I would rather not.
--
Ken Tyler
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken wrote:
> I am perfectly happy with the current behavior and with respect choose
> to disagree with your suggestion.
At the risk of flogging this topic beyond death, I would like to point out that
the default values for translate and rotate are <0,0,0>, but that the default
values for scale are <1,1,1>. In other words, and object that has not been
translated has a default translation of zero on all axes because it hasn't been
translated yet. The same object, if it has been created at a given size, is
scaled to 1 on all axes. In this way, we can move an object along x by typing
"translate x*4," because this is, in effect, a translation of <4,0,0>. In order
to maintain consistency at the user level (I keep hearing that things should
hold true in every case, a scale of our object along y by 2 should be able to
be written "scale y*2," returning the defaults, for an equivalent expression of
<1,2,1>. IMO, the warning (and certainly not an error) should not be given,
because the original assumption that default scaling should be <0,0,0>, is
wrong.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 30 Nov 2001 21:24:42 -0500, Dave Dunn wrote:
> to maintain consistency at the user level (I keep hearing that things should
> hold true in every case, a scale of our object along y by 2 should be able to
> be written "scale y*2," returning the defaults, for an equivalent expression of
><1,2,1>.
But "y*2" is defined as <0,2,0>, regardless of where it's used. If scale
wants to assume that any component that's specified as 0 is really 1, that's
fine, but any mumbo-jumbo about "defaults" is sure to confuse anyone who
really thinks about it, and a warning would be nice for the cases where it
wasn't expected.
Maybe what we need is a switch to turn off that warning, but that's not
likely to happen til 4.0.
--
#local R=rgb 99;#local P=R-R;#local F=pigment{gradient x}box{0,1pigment{gradient
y pigment_map{[.5F pigment_map{[.3R][.3F color_map{[.15red 99][.15P]}rotate z*45
translate x]}]#local H=pigment{gradient y color_map{[.5P][.5R]}scale 1/3}[.5F
pigment_map{[.3R][.3H][.7H][.7R]}]}}}camera{location.5-3*z}//only my opinions
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Dave Dunn wrote:
> to maintain consistency at the user level (I keep hearing that things should
> hold true in every case, a scale of our object along y by 2 should be able to
> be written "scale y*2," returning the defaults, for an equivalent expression of
> <1,2,1>.
But the fact is the scale y*2 is not returing a default value because it
should be promoted to scale <0,2,0>. The truth is the program has fault
handling included to automatically adjust for a user syntax fault and
it issues an appropriate warning to that effect. The alternative is to
remove the fault handling and let it return an error instead. IMO the
automatic fault handling with a warning message is a good compromise.
Warp's suggestion punishes you for using bad syntax :)
--
Ken Tyler
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 30 Nov 2001 19:39:18 -0800, Ken wrote:
> Warp's suggestion punishes you for using bad syntax :)
Typical C programmer. :)
--
#macro R(P)z+_(P)_(P)_(P+1)_(P+1)+z#end#macro Q(C,T)bicubic_patch{type 1u_steps
6v_steps 6R(1)R(3)R(5)R(7)pigment{rgb z}}#end#macro _(Y)#local X=asc(substr(C,Y
,1))-65;<T+mod(X,4)div(X,4)9>-2#end#macro O(T)Q("ABEFUQWS",T)Q("WSXTLOJN",T)#
end O(0)O(3)Q("JNKLCGCD",0)light_source{x 1}// ron### [at] povrayorg
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Wasn't it Dave Dunn who wrote:
>At the risk of flogging this topic beyond death, I would like to point out that
>the default values for translate and rotate are <0,0,0>, but that the default
>values for scale are <1,1,1>. In other words, and object that has not been
>translated has a default translation of zero on all axes because it hasn't been
>translated yet. The same object, if it has been created at a given size, is
>scaled to 1 on all axes. In this way, we can move an object along x by typing
>"translate x*4," because this is, in effect, a translation of <4,0,0>. In order
>to maintain consistency at the user level (I keep hearing that things should
>hold true in every case, a scale of our object along y by 2 should be able to
>be written "scale y*2," returning the defaults, for an equivalent expression of
><1,2,1>. IMO, the warning (and certainly not an error) should not be given,
>because the original assumption that default scaling should be <0,0,0>, is
>wrong.
So, what you're saying, is that when the code that implements "scale" is
passed a value <0,2,0> it would have to look back at the source code and
fine where those values came from. If you had explicitly specified
"scale <0,2,0>" it should display a warning, but if you had originally
specified "scale y*2" the warning should be suppressed. This would get
really tricky if you had written "scale My_Vector" or "scale
My_Macro(2)".
--
Mike Williams
Gentleman of Leisure
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
JRG wrote:
>As you know vectors aren't used exclusively for transformations (i.e.
rotations, >translations and scale), so they must work the same way in any
circumstance. I >mean, if I write y, I mean <0,1,0> (what otherwise?). So, since
rotate, translate and >scale need a vector, and since x, y and z are those
vectors I mentioned above and >HAVE to work the same way everywhere...
If what you are saying is true, the initial value for scale on any given object
would be scale <0,0,0>. In other words, if I want to create "sphere
{<0,0,0>,1}," I would have to write it "sphere {<0,0,0>,1 scale <1,1,1>}" to
make it visible. Since this is not the way it is, I submit that scale is a
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.
Therefore, the warning should not exist, because it is certainly legal to
translate or rotate by a single axis. This, of course, is at the end-user level;
I agree that what happens internally in the source code is another issue.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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. You specify a vector that scales all three axes, every time. That
you didn't specify a valid scale for some axes is taken by the program to mean
that you probably meant one, but it should definitely warn you in case that
isn't the case.
--
plane{-z,-3normal{crackle scale.2#local a=5;#while(a)warp{repeat x flip x}rotate
z*60#local a=a-1;#end translate-9*x}pigment{rgb 1}}light_source{-9red 1rotate 60
*z}light_source{-9rgb y rotate-z*60}light_source{9-z*18rgb z}text{ttf"arial.ttf"
"RP".01,0translate-<.6,.4,.02>pigment{bozo}}light_source{-z*3rgb-.2}//Ron Parker
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> If what you are saying is true, the initial value for scale on any given
object
> would be scale <0,0,0>. In other words, if I want to create "sphere
> {<0,0,0>,1}," I would have to write it "sphere {<0,0,0>,1 scale <1,1,1>}"
to
> make it visible. Since this is not the way it is, I submit that scale is a
> 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.
> Therefore, the warning should not exist, because it is certainly legal to
> translate or rotate by a single axis. This, of course, is at the end-user
level;
> I agree that what happens internally in the source code is another issue.
Thing is, "scale y" doesn't mean "scale <ignore this, 1, ignore this>". It
means "scale <0, 1, 0>". The "y" *explicitly* states zero for the x and z
components of the vector.
- Slime
[ http://www.slimeland.com/ ]
[ http://www.slimeland.com/images/ ]
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Dave Dunn" wrote:
> If what you are saying is true, the initial value
> for scale on any given object would be scale <0,0,0>.
Scale is an operation, not a property of the object. Thus there is no such
thing as an initial scale.
No matter what you say, y is and will always be defined as <0,1,0> and y*2
is thus <0,2,0>. That's how vector operations work. The vector operations
don't care what keyword is in front of them, they always work the same way.
Rune
--
3D images and anims, include files, tutorials and more:
Rune's World: http://rsj.mobilixnet.dk (updated Nov 5)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Dave Dunn wrote:
>
> to maintain consistency at the user level (I keep hearing that things should
> hold true in every case, a scale of our object along y by 2 should be able to
> be written "scale y*2," returning the defaults, for an equivalent expression of
> <1,2,1>. IMO, the warning (and certainly not an error) should not be given,
> because the original assumption that default scaling should be <0,0,0>, is
> wrong.
I disagree. Sometimes the user may write "y*2", but sometimes it may be
caused by a loop or macro and cause unexpected behavior. Then you can
leave a render going for six hours and see a big ugly sphere in the
middle of it. It is *never* good programming practice to modify or
accept erroneous input without telling the user. Warp's idea seems to
have its antagonists, so perhaps POV should have (or does it?) an
configurable option to treat warnings as errors and stop parsing, like
in many compilers.
--
David Fontaine <dav### [at] faricynet> ICQ 55354965
My raytracing gallery: http://davidf.faricy.net/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rune wrote:
>
> "Dave Dunn" wrote:
> > If what you are saying is true, the initial value
> > for scale on any given object would be scale <0,0,0>.
>
> Scale is an operation, not a property of the object. Thus there is no such
> thing as an initial scale.
Precisely.
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*.
--
David Fontaine <dav### [at] faricynet> ICQ 55354965
My raytracing gallery: http://davidf.faricy.net/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
David Fontaine <dav### [at] faricynet> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Dave Dunn" <poi### [at] aolcom> wrote in message
news:3C0AA3D6.396C86A6@aol.com...
> 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),
Yes we know it does, but some of us think the warning is perfectly
legitimate.
> 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>,
It's also easier to get off a mountain by jumping, but most people prefer to
climb down.
> when the internal parser is happily converting those offending 0s to
> 1s anyay.
The point is not whether or not POV strays from what you specify in the
scene file (which is what it's doing), but that it should tell you when it
does so. There's nothing wrong with it's replacing the 0's with 1's, it
just needs to tell you since this is not logical behavior.
...Chambers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"JRG" <jrg### [at] hotmailcom> wrote in message
news:3c0aaac1@news.povray.org...
> If we start to put here and there exceptions to the
> rules, things won't be easier, but harder.
Kind of like the English language :)
...Chambers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ben Chambers wrote:
>Kind of like the English language :)
Interesting that you should mention this. I have been thinking that this
whole discussion mirrors a debate that has been raging for years in the
area of liguistics, between prescriptive and descriptive grammar.
Prescritive grammar is based on the insistance that a set of rules,
formulated over the course of time, must be followed, or the language
will degenerate. Descriptive grammar looks at the way the language is
being used and reformulates the rules to reflect current usage. I happen
to fall into the descriptive category.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Dave Dunn" <poi### [at] aolcom> wrote in message
news:3C0B7B79.EEF09155@aol.com...
> Ben Chambers wrote:
>
> >Kind of like the English language :)
>
> Interesting that you should mention this. I have been thinking that this
> whole discussion mirrors a debate that has been raging for years in the
> area of liguistics, between prescriptive and descriptive grammar.
> Prescritive grammar is based on the insistance that a set of rules,
> formulated over the course of time, must be followed, or the language
> will degenerate. Descriptive grammar looks at the way the language is
> being used and reformulates the rules to reflect current usage. I happen
> to fall into the descriptive category.
Follow ups to p.o.t.
Clearly it is both. Definitions of words must be agreed upon, while room
must be made for new usages. But I must admit that I would be more willing
to argue in favor of the former than the latter if we -had- to have it one
way or another.
Most modern languages are quite expressive. If new words can be added as
new concepts arise, there is no need to re-define the old words. But going
to far in the 'descriptive' direction allows chaos to rule and
misunderstanding erupts in every attempt to communicate. For instance, what
if I use the word "erupts" to mean "decreases" or "is destroyed"?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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
... and this probably could generate a lot of questions from future newusers
after such simple animation render:
// animate it with clock from 0 to 1
#local Clock=1-clock;
#local V=Clock*y;
sphere{-1*y,.1 translate V}
sphere{ 0*y,.1 rotate V}
sphere{ 1*y,.1 scale V}
Warning is a good idea for newusers. Advanced one can switch it off.
ABX
--
#declare _=function(a,b,x){((a^2)+(b^2))^.5-x}#default {pigment{color rgb 1}}
union{plane{y,-3}plane{-x,-3}finish{reflection 1 ambient 0}}isosurface{ //ABX
function{_(x-2,y,1)|_((x+y)*.7,z,.1)|_((x+y+2)*.7,z,.1)|_(x/2+y*.8+1.5,z,.1)}
contained_by{box{<0,-3,-.1>,<3,0,.1>}}translate z*15finish{ambient 1}}//POV35
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Dave Dunn" <poi### [at] aolcom> wrote in message
news:3C0B7B79.EEF09155@aol.com...
> Ben Chambers wrote:
>
> >Kind of like the English language :)
>
> Interesting that you should mention this. I have been thinking that this
> whole discussion mirrors a debate that has been raging for years in the
> area of liguistics, between prescriptive and descriptive grammar.
> Prescritive grammar is based on the insistance that a set of rules,
> formulated over the course of time, must be followed, or the language
> will degenerate. Descriptive grammar looks at the way the language is
> being used and reformulates the rules to reflect current usage. I happen
> to fall into the descriptive category.
I would have to go with prescriptive. Language is very important - not just
for communication, but also in forming our thoughts (this is the main reason
that learning a second language is so highly recommended - it forces you to
learn to restructure your thoughts). Because of this, it is important to
follow grammatical rules. If you do not follow the set grammar, what
happens is not a muddling of the language, but a muddling of your thought
processes.
...Chambers
Post a reply to this message
|
|
| |
| |
|
|
From: Trevor Quayle
Subject: scale by 0 (was Re: Disc which is not flat)
Date: 3 Dec 2001 10:15:13
Message: <3c0b9701@news.povray.org>
|
|
|
| |
| |
|
|
I think it makes sense the way it works at present.
But if people want to scale quickly in one direction without the warnings
why not use a macro?
#macro ScaleIt (s)
#local s=s*<1,1,1>
scale <#if (s.x=0) 0 #else s.x #end,
#if (s.y=0) 0 #else s.y #end,
#if (s.z=0) 0 #else s.z #end>
#end
Instead of using 'scale x*5' and getting a warning or having to type 'scale
<5,1,1>' you just type
'ScaleIt(x*5)'.
I don't really see the point though, I have gotten in the habit of using
'scale <5,1,1>' for continuity sake.
-tgq
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 3 Dec 2001 10:13:54 -0500, Trevor Quayle wrote:
> I think it makes sense the way it works at present.
> But if people want to scale quickly in one direction without the warnings
> why not use a macro?
>
> #macro ScaleIt (s)
> #local s=s*<1,1,1>
> scale <#if (s.x=0) 0 #else s.x #end,
> #if (s.y=0) 0 #else s.y #end,
> #if (s.z=0) 0 #else s.z #end>
Shirley some of those 0's should be 1's.
--
plane{-z,-3normal{crackle scale.2#local a=5;#while(a)warp{repeat x flip x}rotate
z*60#local a=a-1;#end translate-9*x}pigment{rgb 1}}light_source{-9red 1rotate 60
*z}light_source{-9rgb y rotate-z*60}light_source{9-z*18rgb z}text{ttf"arial.ttf"
"RP".01,0translate-<.6,.4,.02>pigment{bozo}}light_source{-z*3rgb-.2}//Ron Parker
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 3 Dec 2001 10:13:54 -0500, "Trevor Quayle" <Tin### [at] hotmailcom>
wrote:
> #macro ScaleIt (s)
> #local s=s*<1,1,1>
> scale <#if (s.x=0) 0 #else s.x #end,
> #if (s.y=0) 0 #else s.y #end,
> #if (s.z=0) 0 #else s.z #end>
> #end
Excuse me, but ... what is purpose of this macro :-)
You probably want
#macro ScaleIt (s)
#local s=s+<0,0,0>;
scale <(s.x=0?1:s.x),(s.y=0?1:s.y),(s.z=0?1:s.z)>
#end
ABX
--
#declare _=function(a,b,x){((a^2)+(b^2))^.5-x}#default {pigment{color rgb 1}}
union{plane{y,-3}plane{-x,-3}finish{reflection 1 ambient 0}}isosurface{ //ABX
function{_(x-2,y,1)|_((x+y)*.7,z,.1)|_((x+y+2)*.7,z,.1)|_(x/2+y*.8+1.5,z,.1)}
contained_by{box{<0,-3,-.1>,<3,0,.1>}}translate z*15finish{ambient 1}}//POV35
Post a reply to this message
|
|
| |
| |
|
|
From: Trevor Quayle
Subject: Re: scale by 0 (was Re: Disc which is not flat)
Date: 3 Dec 2001 11:04:00
Message: <3c0ba270$1@news.povray.org>
|
|
|
| |
| |
|
|
"W³odzimierz ABX Skiba" <abx### [at] babilonorg> wrote in message
news:oh6n0uoqibno6v3ighkgd7moo9u6cm0doi@4ax.com...
> On Mon, 3 Dec 2001 10:13:54 -0500, "Trevor Quayle"
<Tin### [at] hotmailcom>
> wrote:
>
> > #macro ScaleIt (s)
> > #local s=s*<1,1,1>
> > scale <#if (s.x=0) 0 #else s.x #end,
> > #if (s.y=0) 0 #else s.y #end,
> > #if (s.z=0) 0 #else s.z #end>
> > #end
>
> Excuse me, but ... what is purpose of this macro :-)
> You probably want
>
> #macro ScaleIt (s)
> #local s=s+<0,0,0>;
> scale <(s.x=0?1:s.x),(s.y=0?1:s.y),(s.z=0?1:s.z)>
> #end
>
Oops, my mistake, I did mean to use 1s not 0s, and I didn't think of the
conditional operand. Still, there is no real point to it other than to
placate those who don't like the present results of scaling by 0.
Also what would be the difference between
#local s=s*<1,1,1>
and
#local s=s+<0,0,0>
?
-tgq
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
