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?

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.

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.

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

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

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