 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Fri, 16 Aug 2013 20:08:52 +0200, Anthony D. Baye
<Sha### [at] spamnomore hotmailcom> wrote:
> clipka <ano### [at] anonymousorg> wrote:
>> Am 16.08.2013 06:27, schrieb Anthony D. Baye:
>> > I should also be clear that with vrotate(A,B), B is also a vector.
>> So:
>> >
>> > object {
>> > ...
>> > translate vrotate(A, B)
>> > }
>> >
>> > is the same as:
>> >
>> > object {
>> > ...
>> > translate A
>> > rotate B
>> > }
>>
>> Nope. It's rather like
>>
>> rotate <0,0,-B.z>
>> rotate <0,-B.y,0>
>> rotate <-B.x,0,0>
>> translate A
>> rotate B
>
> Then the documentation needs serious clarification. That is not
> mentioned at
> all.
>
> http://www.povray.org/documentation/view/3.7.0/229/
>
> From: Pov-Ray documentation 2.2.1.4 Vector Expressions --
> "vrotate(A,B) Rotate A about origin by B. Given the x,y,z coordinates of
> a point
> in space designated by the vector A, rotate that point about the origin
> by an
> amount specified by the vector B. Rotate it about the x-axis by an angle
> specified in degrees by the float value B.x. Similarly B.y and B.z
> specify the
> amount to rotate in degrees about the y-axis and z-axis. The result is a
> vector
> containing the new x,y,z coordinates of the point."
>
> Regards,
> A.D.B.
>
No wonder I got confused. i thought it was just me...
--
-Nekar Xenos-
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 16.08.2013 20:08, schrieb Anthony D. Baye:
> clipka <ano### [at] anonymousorg> wrote:
>> Am 16.08.2013 06:27, schrieb Anthony D. Baye:
>>> I should also be clear that with vrotate(A,B), B is also a vector. So:
>>>
>>> object {
>>> ...
>>> translate vrotate(A, B)
>>> }
>>>
>>> is the same as:
>>>
>>> object {
>>> ...
>>> translate A
>>> rotate B
>>> }
>>
>> Nope. It's rather like
>>
>> rotate <0,0,-B.z>
>> rotate <0,-B.y,0>
>> rotate <-B.x,0,0>
>> translate A
>> rotate B
>
> Then the documentation needs serious clarification. That is not mentioned at
> all.
>
> http://www.povray.org/documentation/view/3.7.0/229/
>
> From: Pov-Ray documentation 2.2.1.4 Vector Expressions --
> "vrotate(A,B) Rotate A about origin by B. Given the x,y,z coordinates of a point
> in space designated by the vector A, rotate that point about the origin by an
> amount specified by the vector B. Rotate it about the x-axis by an angle
> specified in degrees by the float value B.x. Similarly B.y and B.z specify the
> amount to rotate in degrees about the y-axis and z-axis. The result is a vector
> containing the new x,y,z coordinates of the point."
What you're missing is that
object {
...
translate vrotate(A,B)
}
only translates the object by the offset computed as "vrotate(A,B)", while
object {
...
translate A
rotate B
}
/obviously/ not only translates the object, but also rotates it. If the
object in question is a sphere originally created at <0,0,0> this
doesn't matter, but if it is, say, a cube, then this changes the
orientation of its edges in space.
To compensate for this, you'd have to apply the inverse rotation to the
object first, /then/ translate by A, and finally apply the rotation by
B. This will indeed effectively apply a rotation to the A vector used
for translation, while leaving the object's orientation in space
effectively unchanged.
I think there's no need for additional clarification in the docs, as
this should be obvious enough once you think a few moments about the
features involved (translate, rotate, and vrotate). The docs can't
account for /all/ exotic combinations of features.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
> Am 16.08.2013 20:08, schrieb Anthony D. Baye:
> > clipka <ano### [at] anonymousorg> wrote:
> >> Am 16.08.2013 06:27, schrieb Anthony D. Baye:
> >>> I should also be clear that with vrotate(A,B), B is also a vector. So:
> >>>
> >>> object {
> >>> ...
> >>> translate vrotate(A, B)
> >>> }
> >>>
> >>> is the same as:
> >>>
> >>> object {
> >>> ...
> >>> translate A
> >>> rotate B
> >>> }
> >>
> >> Nope. It's rather like
> >>
> >> rotate <0,0,-B.z>
> >> rotate <0,-B.y,0>
> >> rotate <-B.x,0,0>
> >> translate A
> >> rotate B
> >
> > Then the documentation needs serious clarification. That is not mentioned at
> > all.
> >
> > http://www.povray.org/documentation/view/3.7.0/229/
> >
> > From: Pov-Ray documentation 2.2.1.4 Vector Expressions --
> > "vrotate(A,B) Rotate A about origin by B. Given the x,y,z coordinates of a point
> > in space designated by the vector A, rotate that point about the origin by an
> > amount specified by the vector B. Rotate it about the x-axis by an angle
> > specified in degrees by the float value B.x. Similarly B.y and B.z specify the
> > amount to rotate in degrees about the y-axis and z-axis. The result is a vector
> > containing the new x,y,z coordinates of the point."
>
> What you're missing is that
>
> object {
> ...
> translate vrotate(A,B)
> }
>
> only translates the object by the offset computed as "vrotate(A,B)", while
>
> object {
> ...
> translate A
> rotate B
> }
>
> /obviously/ not only translates the object, but also rotates it. If the
> object in question is a sphere originally created at <0,0,0> this
> doesn't matter, but if it is, say, a cube, then this changes the
> orientation of its edges in space.
>
> To compensate for this, you'd have to apply the inverse rotation to the
> object first, /then/ translate by A, and finally apply the rotation by
> B. This will indeed effectively apply a rotation to the A vector used
> for translation, while leaving the object's orientation in space
> effectively unchanged.
>
> I think there's no need for additional clarification in the docs, as
> this should be obvious enough once you think a few moments about the
> features involved (translate, rotate, and vrotate). The docs can't
> account for /all/ exotic combinations of features.
I wasn't considering the object's orientation, only it's position w/r/t to the
origin, so I guess I was at least partially wrong.
Still, the transformation is not at all as obvious as you say it is: Not
everyone is a wiz at visualizing complex 3D transformations.
Reminds me of math teachers talking to the chalkboard and saying "The obvious
conclusion is..." when it's obvious to them, but they aren't the student.
So, yes, when you experiment with it, it becomes obvious that there is a
pre-translation rotation happening to prevent the object's orientation from
being changed.
Regards,
A.D.B.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 16.08.2013 21:38, schrieb Anthony D. Baye:
>> object {
>> ...
>> translate A
>> rotate B
>> }
>>
>> /obviously/ not only translates the object, but also rotates it. If the
>> object in question is a sphere originally created at <0,0,0> this
>> doesn't matter, but if it is, say, a cube, then this changes the
>> orientation of its edges in space.
>>
>> To compensate for this, you'd have to apply the inverse rotation to the
>> object first, /then/ translate by A, and finally apply the rotation by
>> B. This will indeed effectively apply a rotation to the A vector used
>> for translation, while leaving the object's orientation in space
>> effectively unchanged.
>>
>> I think there's no need for additional clarification in the docs, as
>> this should be obvious enough once you think a few moments about the
>> features involved (translate, rotate, and vrotate). The docs can't
>> account for /all/ exotic combinations of features.
>
> I wasn't considering the object's orientation, only it's position w/r/t to the
> origin, so I guess I was at least partially wrong.
>
> Still, the transformation is not at all as obvious as you say it is: Not
> everyone is a wiz at visualizing complex 3D transformations.
>
> Reminds me of math teachers talking to the chalkboard and saying "The obvious
> conclusion is..." when it's obvious to them, but they aren't the student.
Sorry for the ambiguous wording; I didn't mean to call the details of
the inverse rotation "obvious" (I'm well aware that it isn't), just the
plain fact that
object {
...
translate A
rotate B
}
applies a rotation to the object, while
object {
...
translate vrotate(A,B)
}
doesn't (and as far as the latter is concerned I'm also aware that it's
not necessarily obvious at first glance, hence "obvious enough once you
think a few moments [...]").
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
FURTHER clarified in pbi.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Basically what I need is to duplicate the camera's transformations to the
block.
What is the best way to do that?
-Nekar
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I am trying to duplicate the camera angle in a scene with a box mapped
> with the image, but when I use certain camera positions and look
> combinations, it rotates the image along the z axis. It seems to happen
> when the Camera position and look position don't have the same y value.
>
> How can i fix this?
>
> here is a stripped down version. If the "doesn't work' part is commented
> out it works fine.
>
> I must admit, I don't always know when to use Reorient_Trans() vs
> vrotate() vs VAngleD() and even less how to use them. It gets confusing.
>
>
From the documentations:
"The look_at vector tells POV-Ray to pan and tilt the camera until it is
looking at the specified x, y, z coordinates."
Whenever the y position of the camera and look_at are different, the
camera will tilt up or down,
Depending on the x and z coordinates, and the order of the pan and tilt,
it can look as if the camera did rotate around the z axis as well as the
x axis.
This can cause unexpected result if it cause the camera to look straight
up or down.
When looking straight up or down, you need to provide the up vector.
Another way is to create the camera at the origin, looking toward +z
(the default), and use rotate -90*x to look up and rotate 90*x to look down.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 18.08.2013 22:39, schrieb Alain:
> From the documentations:
> "The look_at vector tells POV-Ray to pan and tilt the camera until it is
> looking at the specified x, y, z coordinates."
>
> Whenever the y position of the camera and look_at are different, the
> camera will tilt up or down,
> Depending on the x and z coordinates, and the order of the pan and tilt,
> it can look as if the camera did rotate around the z axis as well as the
> x axis.
>
> This can cause unexpected result if it cause the camera to look straight
> up or down.
> When looking straight up or down, you need to provide the up vector.
> Another way is to create the camera at the origin, looking toward +z
> (the default), and use rotate -90*x to look up and rotate 90*x to look
> down.
You know what? This sucks. The issue of trying to figure out the camera
parameters crops up so frequently that I think it really needs to be
addressed in the form of an inbuilt feature at the next possible
opportunity.
I'm thinking along the lines of (1) a function (or set of functions) to
retrieve the effective up, right and direction vectors, and (2) a
function (or pair of functions) to return the effective camera position
and direction vector corresponding to any given position in the output
image (x,y ranging from 0.0 to 1.0 each). Also nice to have would be (3)
a function to retrieve the effective camera angle (if applicable for the
selected camera).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Mon, 19 Aug 2013 00:09:35 +0200, clipka <ano### [at] anonymousorg> wrote:
> Am 18.08.2013 22:39, schrieb Alain:
> You know what? This sucks. The issue of trying to figure out the camera
> parameters crops up so frequently that I think it really needs to be
> addressed in the form of an inbuilt feature at the next possible
> opportunity.
I agree.
> I'm thinking along the lines of (1) a function (or set of functions) to
> retrieve the effective up, right and direction vectors, and (2) a
> function (or pair of functions) to return the effective camera position
> and direction vector corresponding to any given position in the output
> image (x,y ranging from 0.0 to 1.0 each). Also nice to have would be (3)
> a function to retrieve the effective camera angle (if applicable for the
> selected camera).
>
That would be fantastic!
and how about a point_at option for objects that works the same way as
look at?
And a "up" option for objects as well.
--
-Nekar Xenos-
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 19.08.2013 05:31, schrieb Nekar Xenos:
> and how about a point_at option for objects that works the same way as
> look at?
> And a "up" option for objects as well.
That sounds more like a job for a macro to me, taking an "up" and
"point_at" parameter and spitting out a rotation transform.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
