 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
<The key to remember, ALL rotations and scalings
<are done with respect to the coordinate axes.
I believe this is the point I'm missing in comprehending pov rotations.
coordinate axes ? To rotate something why should I care about its coordinates.
Shouldn't povray automatically take into account THE coordinates?
Plus first scaling then rotating has direct implications on the new location, as
opposed to only rotating, w/o scaling.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Among other things, mysdn saw fit to write:
> I believe this is the point I'm missing in comprehending pov rotations.
> coordinate axes ? To rotate something why should I care about its
> coordinates. Shouldn't povray automatically take into account THE
> coordinates?
>
> Plus first scaling then rotating has direct implications on the new
> location, as opposed to only rotating, w/o scaling.
Every rotation has to be done *around* something (some point or axis). The
Earth's rotation takes place around its center (more or less), the Earth's
translation is just rotation around the Sun (more or less), the Moon's
movement around the Earth could be simply described as a rotation around
the Earth.
In POV-Ray, rotations are always around the <0,0,0> point. If an object is
positioned at <0,0,0>, rotating it will just rotate the object, but if the
object is 10 units away, its position will change, because it's like there
was a string between the object and a stick atb <0,0,0>: only the <0,0,0>
point stays fixed.
When you want to rotate an object, think which point(s) of the object should
stay completeley fixed in space (the hinges of a door); well, this point
must be placed at <0,0,0> before rotation or else a translation must be
applied to compensate it.
Similarly with scalings, they are done with respect to <0,0,0>. That means a
1-size sphere centered at <0,0,0> scaled by 2, becomes a 2-size sphere
centered at <0,0,0>; but a 1-size sphere centered 10 units away becomes a
2-size sphere centered 20 units away.
--
light_source{9+9*x,1}camera{orthographic look_at(1-y)/4angle 30location
9/4-z*4}light_source{-9*z,1}union{box{.9-z.1+x clipped_by{plane{2+y-4*x
0}}}box{z-y-.1.1+z}box{-.1.1+x}box{.1z-.1}pigment{rgb<.8.2,1>}}//Jellby
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tim, I have some final questions. Then I think I'll comprehend the whole logic
involving rotations. I feel pretty stupid after all these explanations but I
feel if I get an answer to this list everything will fall into place. By the
way this whole concept is not so easy to grasp without some handholding.
I'm already grateful for all the answers.
in a previous post I asked you where did you come up with the numbers you did.
1- In the example you provided one of the corners is
at <-49.999,-49.999,0.001>, and another at
<50.001,50.001,100.001>.
1- Where are these numbers showing in my sample?
2- When you scale you are relocating the corners around the origin by
multiplication. So
0.01*<-49.999,-49.999,0.001> = <-0.5,-0.5,0>, and
0.01*<50.001,50.001,100.001> = <0.5,0.5,1>
2- Why do you multiply 0.01*<-49.999,-49.999,0.001> = <-0.5,-0.5,0>, and
0.01*<50.001,50.001,100.001> = <0.5,0.5,1>
3- So then you have your first wall so you scale by
<250,260,10>*<-0.5,-0.5,0>= <-125,-130,0>, and
<250,260,10>*<0.5,0.5,1>=<125,130,10>
3- Why these 2 multiplications take place?
4- <-0.5,-0.5,0> is the coordinate of of the lower-left-forward corner
of the BOX mesh, which is the _box mesh <-49.999,-49.999,0.001>
scaled by 0.01 (and rounded a bit).
4- Where does it say <-0.5,-0.5,0> is the lower left forward corner of BOX?
5- So the first wall is equivalent to
box{<-250,0,-3.5>,<0,260,6.5>}
5- is <-250,0,-3.5> translate or scale, same question for >,<0,260,6.5>
6- So for this example I'll pick a corner... <-100,-130,0>
6- Which corner is this and how did the number came to be <-100,-130,0>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 1- In the example you provided one of the corners is
> at <-49.999,-49.999,0.001>, and another at
> <50.001,50.001,100.001>.
> 1- Where are these numbers showing in my sample?
The numbers are in the file "box_POV_geom.inc",
as part of the mesh2 definition.
> 2- When you scale you are relocating the corners around the origin by
> multiplication. So
> 0.01*<-49.999,-49.999,0.001> = <-0.5,-0.5,0>, and
> 0.01*<50.001,50.001,100.001> = <0.5,0.5,1>
>
> 2- Why do you multiply 0.01*<-49.999,-49.999,0.001> = <-0.5,-0.5,0>, and
> 0.01*<50.001,50.001,100.001> = <0.5,0.5,1>
<50.001,50.001,100.001> is the upper-right-rear corner of the
box. Again, this is from "box_POV_geom.inc", the multiplication
by 0.01 comes from the scale in line 20 of "rotation.pov"
#declare BOX = object { box_ scale <0.01,0.01,0.01> translate <0, 0, 0> }
Note that translate <0,0,0> doesn't do anything and could be omited.
So we have here the coordinates of two corners of the mesh2 "box_",
which is redeclared as "BOX" and scaled.
> 3- So then you have your first wall so you scale by
> <250,260,10>*<-0.5,-0.5,0>= <-125,-130,0>, and
> <250,260,10>*<0.5,0.5,1>=<125,130,10>
>
> 3- Why these 2 multiplications take place?
In line 25 of "rotation.pov" you scale "BOX".
So these are the coordinates of the object statement started on
line 24, as of the scaling. It's translated later in line 27.
> 4- <-0.5,-0.5,0> is the coordinate of of the lower-left-forward corner
> of the BOX mesh, which is the _box mesh <-49.999,-49.999,0.001>
> scaled by 0.01 (and rounded a bit).
>
> 4- Where does it say <-0.5,-0.5,0> is the lower left forward corner of
> BOX?
POV by default uses a left handed coordinate system... so plus Y is
up, plus X is right, plus Z is away. It's called left handed because
you can hold your left hand with the thumb up (Y), the pointer finger
forward (Z), and the middle finger right (X) to visualize the XYZ axis.
You can also picture the direction of rotations that way. If you make
the XYZ axis with your left hand, then if you trace from the palm
of the left hand over the middle finger, that's positive X, and
continue tracing over the middle finger, that's positive Z, and then
tward you around the thumb, that's positive Y.
So it's that corner because it was the vector with the minimum values.
Note that in this case the corner happened to be equal to the result
of the min_extent function, but it's not required to be equal.
> 5- So the first wall is equivalent to
> box{<-250,0,-3.5>,<0,260,6.5>}
>
> 5- is <-250,0,-3.5> translate or scale, same question for >,<0,260,6.5>
Yeah, box{<-250,0,-3.5>,<0,260,6.5>} should be equivalent to
the first wall, as per line 24-28 of "rotation.pov", that's what
is going on. It's just a mental stand-in for the mesh, which in
the sample is actually a box, but if the mesh is somewhat box-like
(say a cabinet) it's still a valid picture of where it is.
> 6- So for this example I'll pick a corner... <-100,-130,0>
> 6- Which corner is this and how did the number came to be <-100,-130,0>
It's the front-left-bottom corner of the second wall,
declared as "ek_duvar12" in line 33-41 of "rotation.pov".
Which is <-0.5,-0.5,0>*<200,260,15>, the
corner of "BOX" scaled as per line 36.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Tim Attwood" <tim### [at] anti-spam comcastnet> wrote:
> POV by default uses a left handed coordinate system... so plus Y is
> up, plus X is right, plus Z is away. It's called left handed because
> you can hold your left hand with the thumb up (Y), the pointer finger
> forward (Z), and the middle finger right (X) to visualize the XYZ axis.
As a side note, I think this is an extremely ugly way of defining a "left
handed" coordinate system, because it appears somewhat arbitrary: If your Y was
away and Z was up, would it still be a left-handed system? After all, you could
point the fingers of your left hand in exactly the same way, just "numbering"
them differently.
The answer is "no", but the description gives no hint why that would be a
right-handed coordinate system instead.
It gets clearer when one introduces a strictly systematic "naming" for the
fingers: Starting from the thumb, call your fingers "X", "Y" and "Z". So point
your thumb to the right (X), your index finger up (Y), and your middle finger
away (Z).
> You can also picture the direction of rotations that way. If you make
> the XYZ axis with your left hand, then if you trace from the palm
> of the left hand over the middle finger, that's positive X, and
> continue tracing over the middle finger, that's positive Z, and then
> tward you around the thumb, that's positive Y.
This, too, appears to be quite arbitrary. There's another, IMHO much more
intuitive way to picture rotation in a left-handed coordinate system:
Make a "thumbs up" sign with your left hand. Hold it so that your thumb points
into the direction you're rotating about. Rotating by a positive value now
corresponds to moving along your curved fingers towards the fingertips.
Same gymnastics work accordingly for a right-handed coordinate system, of
course. Just use your right hand then.
Unfortunately, the POV-Ray documentation is somewhat inconsistent about how to
visualize handedness; while "2.2.1.1 Understanding POV-Ray's Coordinate
System" uses the imagery I just described, "3.3.1.1.7 Handedness" uses the
more contrived variant for depicting the coordinate axes with your hand (but
just refers to 2.2.1.1 for rotation).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thanks to all contributors in this thread.
Larry, clipka, Jellby, Chris B and especially Tim AttWood.
This was an exercise for professional reasons not hobby,so it's pretty important
for me. I appreciate everything you guys have done. I will take about a week to
digest all your posts and if you don't hear from me again in about a week you
can assume I got it, thanks to you helpful people. I would share my knowledge
in a split second if somebody asked for it too.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi, thank you guys, I can now rotate a wall attached to another.
But I realize my problems are much bigger than that or so they seem.
I can't do rotation when using Unions, I posed a few more questions in the zip
file which can be dowloaded from
http://ompf.org/forum/download/file.php?id=249
Note: you can paste this into your browsers addres bar and press Enter, download
dialog will pop up.
My God, It's as if I sensed rotations would send me berserk from last year.
On this subject I'm free falling. At the mercy of people like you guys. Thanks.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Hi, thank you guys, I can now rotate a wall attached to another.
> But I realize my problems are much bigger than that or so they seem.
>
> I can't do rotation when using Unions, I posed a few more questions in the
> zip
> file which can be dowloaded from
>
> http://ompf.org/forum/download/file.php?id=249
>
> Note: you can paste this into your browsers addres bar and press Enter,
> download
> dialog will pop up.
>
> My God, It's as if I sensed rotations would send me berserk from last
> year.
> On this subject I'm free falling. At the mercy of people like you guys.
> Thanks.
Here's an example of how I would do it with your meshes.
Maybe that will help you more.
http://news.povray.org/povray.binaries.scene-files/attachment/%3C4a40205e%40news.povray.org%3E/us-ascii
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tim,
I can't tell you enough how much I appreciate your input. Latest example was
brilliant it gave me some ideas on how to proceed, but some issues still
remain.
You must be an angel for having the patience to bear with me. This thread will
be a godsend for those who will follow this trail.
1- // the angled cabinet
object {
CABINET
translate <0,0,60> // place front-left-bottom corner on origin
1- Why do we translate to <0,0,60>, what if I want to rotate around right front
corner then what would this value be ? I think this point needs elaboration.
Did you multiply <-0.5,-0.5,0>*<x,x,x>?
2- Declaring a Cabinet Union, then just copying and placing them on the scene is
brilliant. That's the route I want to go for each similar object. But each
cabinet may have different texture, handle, door model applied to it.
So in
// the left cabinet
object {
CABINET
translate <0,0,0>
rotate <0,0,0>
translate <0,10,0> // raise bottom of cabinet to kick height
}
How should I proceed to reflect these different characteristics in the object?
I have a feeling these won't be my last questions.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tim,
on second thought, I don't think I can use
// cabinet
#declare CABINET = union {
// case
object{
box_ //
because as I said each cabinet may have different characteristics, even no
characteristics such as no door, no handle, then our "declare CABINET" would be
useless, cause it defines a solid , fixed model. We need an adjustable model
definition, with following specifications adjusted diffrently for each cabinet.
location
scale
case texture
door texture
handle texture
door model
handle model
all these may be diffrent for each cabinet, I think we should construct a
separate Union for each cabinet, What do you think? My previous post questions
still valid. Thank you.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
