 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] povray org
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
|
|
| |
| |
|
|
|
|
| |
|
|
