Jump to content
  • Advertisement

Recommended Posts

Hello. I'm reading learnopengl_fps_camera and i don't understand Euler angles from it. 

It says that:

1)

direction.y = sin(glm::radians(pitch)); it's clear.

2)

direction.x = cos(glm::radians(pitch));
direction.z = cos(glm::radians(pitch));

It's not clear why x and z are changed equally. What if we look at only one axis?

3)

direction.x = cos(glm::radians(pitch)) * cos(glm::radians(yaw));
direction.y = sin(glm::radians(pitch));
direction.z = cos(glm::radians(pitch)) * sin(glm::radians(yaw));

Why multiplication?

 

Share this post


Link to post
Share on other sites
Advertisement

Its because cosine of 90 180 equals to 0

This will grant stable forward look when you look directly up or down. Resulting (0,1,0) for up and (0,-1,0) for down???...

Dont forget to normalize it again...

Share this post


Link to post
Share on other sites
11 minutes ago, _WeirdCat_ said:

Its because cosine of 90 180 equals to 0

This will grant stable forward look when you look directly up or down. Resulting (0,1,0) for up and (0,-1,0) for down???...

Dont forget to normalize it again...

is it second case? Still not clear.

We look at z axis and slowly moving our head up. I understand why z and y are changing by cos and sin but why x? Or is it because direction.x will be 0 if we look at z? Hmm, looks easy now.

Share this post


Link to post
Share on other sites

Pitch means up down 

Yaw is left right

consider pitch 90 degrees it points up

direction.x = cos(glm::radians(pitch)) * cos(glm::radians(yaw));
direction.y = sin(glm::radians(pitch));
direction.z = cos(glm::radians(pitch)) * sin(glm::radians(yaw));

 

float cosp = cos(90*(pi/180)) ; => equals to 0

direction.x = cosp * cos(yaw); 0

direction.y = sin(pitch); 1

direction.z = cosp * sin(yaw); 0

assuming that x points right y points up and z points forward

this gives you 0,1,0 vector which points up.

if you look directly at z your yaw angle is equal to 90 degrees pitch in that case is 0 degrees

so the initial vector when you look at z direction is

x = cos(0)*cos(90); = 0

y = sin(0); = 0

z = cos(0)*sin(90); = 1

when you pitch up or down yaw angle doesn't change its still 90 which equals to 0 for cosine(90degs)

Remember that you renormalize that result cause it wont be of size 1 everytime

 

Share this post


Link to post
Share on other sites
Posted (edited)

Thank you, now i see it works because of yaw.

In that book they first show the formula of pitch and it's not clear at all why it should work. But we must see how it works with pitch and yaw combined. Yaw in that case behaves like projection on x and z. First we project yaw on x an z then we apply pitch and everything is fine. It's like yaw is transformation in x/z plane and pitch transformation takes it to 3d(yaw x/z plane and y). Clever trick.

Edited by _Flame_

Share this post


Link to post
Share on other sites
Quote

It's not clear why x and z are changed equally. What if we look at only one axis?

Although I think I know what the article is trying to convey, I think this part:

direction.x = cos(glm::radians(pitch));
direction.z = cos(glm::radians(pitch));

Is a bit confusing. I would just ignore it and focus on the final result, that is:

direction.x = cos(glm::radians(pitch)) * cos(glm::radians(yaw));
direction.y = sin(glm::radians(pitch));
direction.z = cos(glm::radians(pitch)) * sin(glm::radians(yaw));

Also, I don't think _WeirdCat_ is correct that normalization is needed (unless I'm misunderstanding what _WeirdCat_ is saying, which is possible). The result should be unit length to begin with (within numerical limits of course).

In your last post it looks like you figured everything out, but just for clarity, these are spherical coordinates:

https://en.wikipedia.org/wiki/Spherical_coordinate_system

In that article you can see a conversion similar to yours (although the details differ due to differing conventions).

Share this post


Link to post
Share on other sites
Quote

Normalization is required

I won't outright say you're wrong, because I always want to allow for the possibility that I'm the one who's in error. But I think you're mistaken.

The algorithm in question is a spherical coordinate conversion. The first thing to note is that polar coordinates lie on a circle. Spherical coordinates can be thought of as the 3-d corollary. If that's accurate, then spherical coordinates (at least in the form under consideration here) lie on a sphere, in which case no normalization is needed (in the OP's case, the radial distance is implicitly 1).

Here's another way to think about it. If we start with:

x = cp*cy
y = sp
z = cp*sy

Where c = cos, s = sin, y = yaw, and p = pitch, then the coordinate when yaw = 0 is:

x = cp
y = sp
z = 0

Clearly this is unit-length. Intuitively, rotating the vector around the yaw axis shouldn't change the length. This is further evidence that normalization isn't needed.

This page includes an applet that might be illustrative. It allows you to change the spherical coordinate parameters and see visually (sort of) that the point always lies on the same sphere.

We should also be able to show mathematically that normalization isn't required. If the result is in fact always unit-length, then this should be true:

cp*cp*cy*cy + cp*cp*sy*sy + sp*sp = 1

We know that:

ct*ct + st*st = 1

Where t is an angle theta (y or p in this case). Further:

cp*cp*cy*cy + cp*cp*sy*sy = cp*cp(cy*cy+sy*sy) = cp*cp*1 = cp*cp

Therefore:

cp*cp*cy*cy + cp*cp*sy*sy + sp*sp = cp*cp + sp*sp = 1

Not to be contrary, but I'm not sure merely asserting that normalization is required is sufficient here. I think for the benefit of the OP and other readers, a link to a source or an explanation of what you mean would be helpful. (It's possible, for example, that we're actually talking about different things, which does sometimes happen in these sorts of discussions.)

Share this post


Link to post
Share on other sites
Posted (edited)

while that's being sorted, I thought I'd mention (- -)

On 3/29/2019 at 11:12 AM, _Flame_ said:

Why multiplication?

is answered by (- -)

50 minutes ago, Zakwayda said:

Clearly this is unit-length. Intuitively, rotating the vector around the yaw axis shouldn't change the length. This is further evidence that normalization isn't needed.

in case you missed it. You could say that it's to scale the input numbers by the desired projection in unit space.

I like this thread. This was one of my biggest hurdles. Once I got past the trigonometry part, moved my attention to vector algebra and the dot product appeared, it was quite familiar when using it as a perpendicular projector. Especially with some of the given equality laws earlier in this thread. 

Back when, I saw the dot product definition and realized the fancy cos that was a mystery black box actually had a simple arrangement of a couple multiplications and additions. (within unit space) Sometimes I wonder why we don't teach vector math first.

nice one...

Edited by GoliathForge
couple dead keyboard keys needed pounding...

Share this post


Link to post
Share on other sites

Hm maybe this would do:

Pitch 73

Yaw = 45

cos(73) = 0.29237170472

sin and cos of 45 equals to 0.70xxxxx

now lets say we have start pitch 0 which says cos (0) = 1

0.7×0.7+0.7×0.7 = 0.98

sin(73) = 0.95630475596

Cos(73) = 0.29

Sqrt(1.88) close to 1 but not enough

We normalize it

Still not convinced? 😜

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!