I had a fairly complex scene going and and I wanted to do basically this:

camera {<0,10,-10> look_at <0,10,0>} //looks forward along z axis
sphere {<0,9,-5>,.3 scale <0,0,2>}

that is, scale a sphere to double its original size in the +z and -z
directions,
making an egg sort of shape.  It was to be used as an endcap to a cylinder
going from 5 to -5 along the z axis. 
-I checked the sphere coordinates to make sure I wasn't making it at +z
instead
of - z.
-I checked the camera coordinates.
-I checked the scale syntax to make sure I wasn't scaling just the texture.
-I checked that the sphere's diameter was large enough to see.
-I made it a bright red pigment to make sure it wasn't getting lost in the
background.
-it hadn't been translated in place, it was at the coordinates described.

basically if I erased the scale <0,0,2> the sphere appeared where it ought
to be just fine.  If I put it back, it disappeared from the scene.  I think
I ended up making a larger one and flattening it along the y axis.

But I'm still curious as to what happened.

Post a reply to this message

CreeD wrote:
> 
> I had a fairly complex scene going and and I wanted to do basically this:
> 
> camera {<0,10,-10> look_at <0,10,0>} //looks forward along z axis
> sphere {<0,9,-5>,.3 scale <0,0,2>}
> 
> that is, scale a sphere to double its original size in the +z and -z
> directions,
> making an egg sort of shape.  It was to be used as an endcap to a cylinder
> going from 5 to -5 along the z axis.
> -I checked the sphere coordinates to make sure I wasn't making it at +z
> instead
> of - z.
> -I checked the camera coordinates.
> -I checked the scale syntax to make sure I wasn't scaling just the texture.
> -I checked that the sphere's diameter was large enough to see.
> -I made it a bright red pigment to make sure it wasn't getting lost in the
> background.
> -it hadn't been translated in place, it was at the coordinates described.
> 
> basically if I erased the scale <0,0,2> the sphere appeared where it ought
> to be just fine.  If I put it back, it disappeared from the scene.  I think
> I ended up making a larger one and flattening it along the y axis.
> 
> But I'm still curious as to what happened.

It is a bit difficult to explain but suffice it to say that when you
scale an object that is not centered at the origin (i.e. at xyz = 0)
it has the same effect as translating the object. In this case you
are better off building your sphere at the origin, scaling it to
the dimensions that you need, and then translating it into position.

camera {<0,10,-10> look_at <0,10,0>}
sphere {<0,0,0>,.3 scale <1,1,2> translate <0,9,-5>}

Also you should always scale by a number smaller or greater than zero
or POV-Ray will automatically scale it to a value of one for you. In
the example you provided you had your scale set to <0,0,2> which
POV-Ray automatically adjusted to <1,1,2> for you. In this case it
really didn't matter but it is not a good habit to get into. In fact
if you look at the message window POV-Ray probably issued a warning
to this effect.


Cheers,

-- 
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

"CreeD" <mes### [at] nqinet> wrote in message
news:01bfe74e$2924b4c0$021ba1d0@mk...

> ... scaled object and it disappeared.

When you scale an object, all that POV does is to move all parts of the
object from their origin to their origin*scale.

If a point of your object is at <0,0,0>, then that point will stay at
<0,0,0>, since 0*anything = 0. However, if no point of your object rests on
<0,0,0>, then all bets are off.

For example:

sphere{<0,1,0>, 1 scale 2} // the bottom of the sphere will stay at <0,0,0>
since it was their to start with. The top of the sphere moves from y=2 to
y=4.

sphere{<0,1,0>, 0.5 scale 2} // the bottom of the sphere moves from y=0.5 to
y=1. The top of the sphere moves from y=1.5 to y=3

In general, make sure that all objects have a point at <0,0,0>, perform your
scaling and then translate. The general order for transformations is: scale,
rotate, translate. There will be many times when you will deliberately want
to break one or all of these rules, but only break them when you know why
you are breaking them. A good example would be creating the
minute-indicators around the edge of a clock. Then it makes sense to
translate first, rotate second.

To help me remember the order, I use my door rule. You open a door by first
SCALING your hand to the door-knob, then ROTATING the handle, and finally by
TRANSLATING the door.

The door rule is non-copywrited and may be modified and distributed without
restrictions. ;)

Post a reply to this message

Ken wrote:
> 
> Also you should always scale by a number smaller or greater than zero
> or POV-Ray will automatically scale it to a value of one for you. In

Not quite exact. Values below zero mirror the object. Only an exact
zero leads to a scaling factor of one.

Markus

Post a reply to this message

In article <396495EE.C6AD90B6@student.uni-siegen.de>, Markus Becker 
<mar### [at] studentuni-siegende> wrote:

> Ken wrote:
> > 
> > Also you should always scale by a number smaller or greater than zero
> > or POV-Ray will automatically scale it to a value of one for you. In
> 
> Not quite exact. Values below zero mirror the object. Only an exact
> zero leads to a scaling factor of one.

"by a number smaller or greater than zero"
"smaller" == "less than" == "below"
:-)

-- 
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/

Post a reply to this message

Tom Melly <tom### [at] tomandluf9couk> wrote:
: When you scale an object, all that POV does is to move all parts of the
: object from their origin to their origin*scale.

  Well, this is the impression you get, but strictly speaking it's not true.
  Povray doesn't move anything (it doesn't _add_ anything to the location of
the object).
  Objects do NOT have origin. Povray does NOT know where the origin of an
object is.
  Ok, ok, let me take that back. Povray does know where the origin of an
object is: It's at the global origin (ie. coordinates <0,0,0>). What I meant
was that in povray's inner world there's no such a thing as "object origin".
  Objects are basically mathematical functions with a matrix transformation
applied to it. Mathematical functions do not have "origins" except the one
at <0,0,0>.
  For some objects one could think of a logical origin. For a sphere it would
be its center. For a box it would be the exact middle of a box.
  But for other objects this can be a lot more difficult. As an example, let's
take a triangle. What is the "center", the origin of a triangle? Is it the
point which distance is equal to all the sides? Is it the point where the
perpendicular lines through the middle of the sides coincide? Is it the point
where half-angle lines from each corner coincide? Perhaps it's the average
of the vertex points? The list is almost endless and most of those points are
different for most triangles.
  So povray doesn't even try to guess. For it (uh, I should say "she" instead)
the origin of the object is the mathematical origin, period.
  You can easily apply transformations relative to whatever "origin" you want:

translate -MyOrigin
(transform in whatever way I like here)
translate MyOrigin

  Now, what happens with scaling?
  Scaling is just a multiplication. If you scale by 2, the object size is
multiplied by 2.
  Well, what exactly happens is that the local "universe" of the object is
divided by two (with the matrix applied to the object), so that the object
is locally in a "universe" with a 1/2 scaling.
  So it doesn't matter where the object is. Every point in the surface of
the object will be twice as far from the origin than before the scaling.
  If the object is located so that "your" origin is at <0,0,0>, then you get
the effect you expected, ie. the surface goes twice as far from <0,0,0> than
before, ie. it's twice as big.
  If "your" origin is not at <0,0,0> and since every point will be twice
as far from <0,0,0>, you will end up with "your" origin being twice as far
from the origin as before.

  If you didn't read anything else, read at least that last paragraph. It
summarizes what's happening.

  Now, this is easy to understand (or at least I hope so). But let's not
talk about non-uniform scaling... :)
  (Although there's nothing mysterious there: The only difference is that
scaling is performed in a component-by-component basis, so that you have
to think about the points as separate coordinate components.)

  So povray doesn't "translate" anything (since translation is adding something
to the points), it just multiplies.

-- 
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

OK, and there is probably nothing wrong about it.

But I wonder if it would be possible to write a macro which does the
following:
1. Translate the Object which is specified by a parameter to the Origin
(with whatever point one chooses for the non-existing origin of the object)
2. Rotate or scale or whatever the Object by a specified (through a
parameter) amount
3. Translate the Object back to its place

It might be useful or not :-), but I don't know if it is possible to find
out where a Object is, say you have a sphere at <10,0,10>. Is it possible to
get this vector from the "sphere-statement" (without declaring it
previously)? Did not here about something like this yet.

Marc-Hendrik

Post a reply to this message

On Thu, 6 Jul 2000 20:58:49 +0200, Marc-Hendrik Bremer wrote:
>OK, and there is probably nothing wrong about it.
>
>But I wonder if it would be possible to write a macro which does the
>following:
>1. Translate the Object which is specified by a parameter to the Origin
>(with whatever point one chooses for the non-existing origin of the object)
>2. Rotate or scale or whatever the Object by a specified (through a
>parameter) amount
>3. Translate the Object back to its place

If you look through some (really) old posts on povray.windows you'll find 
some reference to macros that do what you want and more.  The post says 
they don't work due to a bug, but the bug's been fixed in 3.1g.  Here's
the relevant headers from the most useful post in the thread, but it's 
educational to read the whole thread (except the flamewar parts.)

From: par### [at] my-dejanewscom (Ron Parker)
Newsgroups:   povray.windows
Subject: Re: Local Transformations
Message-ID: <36962501.0@news.povray.org>
Date: 8 Jan 1999 10:32:17 -0500
Xref: news.povray.org povray.windows:2401

>It might be useful or not :-), but I don't know if it is possible to find
>out where a Object is, say you have a sphere at <10,0,10>. Is it possible to
>get this vector from the "sphere-statement" (without declaring it
>previously)? Did not here about something like this yet.

That doesn't make sense.  Where is a box?  Where is a complex mesh object?
Where is an isosurface that simulates an asteroid field?  Where is 
union {sphere{0,1} sphere {20,1}}?  (I think you'll find that this is covered
in more detail in the other thread, too.)

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message
news:<3964c652@news.povray.org>...
> Tom Melly <tom### [at] tomandluf9couk> wrote:
> : When you scale an object, all that POV does is to move all parts of the
> : object from their origin to their origin*scale.
>
>   Well, this is the impression you get, but strictly speaking it's not
true.
>   Povray doesn't move anything (it doesn't _add_ anything to the location
of
> the object).
>   Objects do NOT have origin. Povray does NOT know where the origin of an
> object is.
>   Ok, ok, let me take that back. Povray does know where the origin of an
> object is: It's at the global origin (ie. coordinates <0,0,0>). What I
meant
> was that in povray's inner world there's no such a thing as "object
origin".
>   Objects are basically mathematical functions with a matrix
transformation
> applied to it. Mathematical functions do not have "origins" except the one
> at <0,0,0>.

I realise this; however, it was explanations like this that confused the
hell out of me when I first started using POV ;) Actually, if you re-read
what I was said, you will see that we agree - just some of my terminology
differs (yours is more correct). For example, I in no way refer to objects
having an "origin" in the sense of "center". By "origin", I mean "the place
occupied by any point of an object before it is transformed", rather than
one absolute. In my examples I tried to make it plain that only that point
of an object whose origin (in my sense) resided at <0,0,0> before scaling
would remain in the same place (<0,0,0>). Even the text you posted from my
original post makes this clear ("all parts").

As for the rest, as I've said I can't find anything that really contradicts
in any fundamental way anything I wrote. More accurate, yes - but I'm not
sure how helpful matrixes are in newusers. "Move" may not be an accurate
word when talking about scaling, but it can be a helpful model when first
understanding transformations.

The trouble with learning to ray-trace is that you start with your standard
tiled floor reflecting sphere schtick, you get cocky, try modelling a
teapot, and suddenly your handle is in Havana. All you did was translate it
1 unit right (the problem is that that was before you scaled it by 500).

Post a reply to this message

Ron Parker schrieb in Nachricht ...
[...]
>From: par### [at] my-dejanewscom (Ron Parker)
>Newsgroups:   povray.windows
>Subject: Re: Local Transformations
>Message-ID: <36962501.0@news.povray.org>
>Date: 8 Jan 1999 10:32:17 -0500
>Xref: news.povray.org povray.windows:2401
>


Very interesting (that "Who is Thorsten Froehlich"-part was great :-)).

[...]
>That doesn't make sense.  Where is a box?  Where is a complex mesh object?
>Where is an isosurface that simulates an asteroid field?  Where is
>union {sphere{0,1} sphere {20,1}}?  (I think you'll find that this is
covered
>in more detail in the other thread, too.)


You are of course right and I get the point. But if you would define any
point related to the object  (say
<(maxx-minx)/2,(maxy-miny)/2,(maxz-minz)/2>) and return this if the function
Whereis{Object} is called, it would make some thinks easier (not much, but
sometimes it may help).

You could achieve this with the megapov-keywords min_extend and max_extend,
if I get this right. How accurate are the bounding boxes of the 'primitive'
pov-primitives like spheres, boxes, cones, cylinders? Is the object
'centered' in there. I know this is not a accurate term, 'course where is
the center? What I mean is: would min_extend.x and max_extend.x return -1
and 1 for a sphere{0,1}, a box{-1,1}, a cone {<-1,0,0>,1,<1,0,0>,2}?

I'm just curios, hope I do not annoy anyone :-)

Marc-Hendrik

Post a reply to this message