Moving The Camera // OpenGL Tutorial #14

[@JoelMarkley-t4i]

Seriously the best tutorials I've seen for OpenGL thus far! The quality of every video is amazing, there's a perfect balance of theory and application, and you can easily tell that you're extremely talented with OpenGL.

[@OGLDEV]

Wow, thanks!

[@VictorGordan]

Congrats on 500 subs! :)

[@OGLDEV]

Thanks!

[@krzysztof588]

what an absolute lad

[@OGLDEV]

Thanks!

[@laurentbedief2199]

thanks for this new chapter !!!!

[@OGLDEV]

You're welcome!

[@yuhaohan1451]

Thank you very much for the excellent tutorial!

[@OGLDEV]

You're very welcome!

[@coderedart]

I finally understood a lot of little things that were not clear before. the left handed system, and which way the crossproduct points to, what the target in the glm::LookAt function meant and what is it used for in combination with up and such. great video, although i prefer the dinosaur toy compared to the pens/pencils as vectors, as it feels natural to think of the front/target vector, up vector and right vector for dino. I now also get why knowing the math behind such convenience functions is important. its like i can "see" what's happening whenever i use functions such as lookAt or perspective.

[@OGLDEV]

It's a dragon! :-) I thought the toy was more appropriate for object/world transformations but I'll see if there is more opportunity to use it in the future. Totally agree with your last statement about math. John Carmack used to say that you have to "know it cold" (I think I read it in "Masters Of Doom"). That is, understand every detail so that when they wake you up at 4AM you can still explain everything about the perspective projection matrix... Definitely important as you move on to more advanced techniques.

[@thebasicmaterialsproject1892]

thanks its a big help

[@OGLDEV]

You're welcome :-)

[@kaiweiyeo4279]

Hi Etay, I managed to compile the code but there's something odd. The other inputs are correct since it's moving the camera, not the cube. PROBLEM: However, the key 'D' can be pressed for input, even though it's not a case in the switch statement.

[@OGLDEV]

Thanks for the bug report. Turns out that I'm handing the special keys (arrows) in a function registered for the regular keys using glutKeyboardFunc. I should have registered a different callback using glutSpecialFunc and handle the arrows there. The code for 'D' is 0x64 which is used for GLUT_KEY_LEFT and this is causing the confusion.

[@Byynx]

In that left and right camera movent if the cross product is always changing the x axis of the camera position(m_pos) why doing the cross product and not just change directly the z component of m_pos ? Why do we need to use cross product?

[@OGLDEV]

It is the X axis in the world. Left/right movement refers to a direction perpendicular to the target vector of the camera. But in the world the camera may be pointing 360 degrees all around so we have to use a dot product to calculate the X axis in the world.

[@illidan-gb9sk]

How are you able to strafe (moving left/right/up/down and still looking straight) with only modifying the camera position and not touching the target vector?

[@OGLDEV]

When you press left or right calculate the left vector by doing a cross product between the forward/target vector and the up vector. Depending on the order you may get the right vector instead. Make sure this vector is normalized (if the inputs are known to be normalized then the result will also be normalized). Scale this vector by the speed of the camera/viewer and add or substract it from the position vector, depending on the key that was pressed. Since you didn't touch the target vector the camera will keep pointing towards the same direction.

[@illidan-gb9sk]

@@OGLDEV Sorry, I I didn't explain myself properly: Around 21:10, where you showcase strafing, we clearly see that the position of the camera is moving and so does the target vector since the cube isn't at the center anymore (and even disappearing). If moving left would be a simple translation of going from (0,0,0) to (-1,0,0), since the camera is still looking at (0,0,0), the cube should remain at the center of the screen. Or I'm missing something (and that worries me 😅).

[@OGLDEV]

When we strafe the code that gets executed is in Camera::OnKeyboard (camera.cpp:40) and it is as I explained - only the position is changed and the target vector remains the same. I think that the source of the confusion is that difference between a vector as a position and a vector as a direction. The camera has both. If you don't change the target vector the camera will keep facing the same direction. For example, if the target vector is (0,0,1) it means that you always face the "forward" direction of the world (or "backward" on a right handed coordinate system). You can move the camera wherever you want and it will continue facing the same direction. To keep the camera pointing at the center of the screen where the cube is located you will need to subtract the position of the camera from the position of the cube and use the result as the target vector. This is a very common technique in many games which are 3rd person based. You control the hero and the camera is hovering high up from some distance and the target vector is calculated as above to keep the hero at the screen center regardless of position (hero/camera).

[@illidan-gb9sk]

@@OGLDEV Thanks! You were 100% right. I was using glm::lookAt() since you said it was the same as InitCameraTransform that's what got me confused. In glm::lookAt, the n vector is called f and computed like this: const f(normalize(center - eye)); So whatever the position of the camera is, it will always face toward the center.

[@OGLDEV]

I guess I missed the part where InitCameraTransform takes a target and up vectors and calculates the transformation matrix where glm lookAt also takes the position of the viewer and the position of the object that you want to focus on and calculates the target vector as you described. So yeah, they are not the same...

[@AlFredo-sx2yy]

hey thanks a lot for this tutorial series, i hope you can read my comment and answer this question. In the WorldTrans::Rotate function, shouldnt we sanitize the inputs? Like, make sure that when we assign the values to rotation.x, .y, .z, we dont assign values that are higher than 360 degrees. I know this should not matter as OpenGL does render numbers higher than that correctly, but there would be a point in which if we added a high enough amount of rotations that we would start to lose precision due to how floating point numbers work, right?

[@OGLDEV]

Sine and Cosine are both periodic functions so if you add 360 degrees you end up with the same result. If you want to add checks for that because you are worried that it might indicate a user error that's fine but I don't think there is an accuracy problem there.

[@AlFredo-sx2yy]

@@OGLDEV In your WorldTrans::Rotate function, you add 3 floating point numbers to your x,y and z rotation values. The problem i see is that if i were to misuse this function by doing, say, something like: Whatever.WorldTrans.Rotate(0.1,0,0); inside of a loop, for example, i would keep adding 0.1 to my rotation in the X component forever. When you start to get to really big numbers, floating point numbers lose precision, so technically, there would reach a point where the object would no longer rotate because it would not be able to handle a rotation as small as 0.1. This point of course would take real long to reach, but it would be reached eventually if i were to keep a program running forever, or if i were to perform a rotation with bigger numbers, i would technically freeze one axis that way. That's why i was wondering if it would make sense to make some sort of if check inside or if it wouldnt really matter since it would be almost impossible to ever reach this point. Anyways, thanks a lot for the information, this is a great series and i look forward to learning more from it!

[@OGLDEV]

@@AlFredo-sx2yy Maybe the trig function developers are doing some kind of a modulo to keep the actual value that goes into sine/cosine lower. In the case of many small increments you can do it yourself.

[@AlFredo-sx2yy]

​@@OGLDEV yes, thats what i thought but the problem is that modulo is not a valid operation for floating point numbers, so i guess the only sensible solution would be through divisions. In any case, i just asked in case you knew what the most popular solution is, since, from what i've seen, no game engine or 3D modelling program seems to care about this problem. I guess that's because if you do things right and never use crazy values or perform incorrect operations, then you should never find yourself in that range of values. But you can test it yourself, go into unity or unreal or blender and set the rotation to some absurdly high value that will be automatically replaced by the engine with the highest possible floating point number they can hold. Then try to add 0.1 to their rotations. The object will simply not move, because that level of decimal precission has been lost at such high values... So i am concerned about reaching that point ever by accident during runtime, but i guess it is really a rare situation. If yo use a value that is about idk, something like 330000000 degrees, you will start to see that your rotations lose a lot of precision and that you will start doing increments by full units (even rotation 1 single degree alone becomes impossible at that point due to floating point precission), so that is something that sort of worries me, but since no game engine or 3D modelling program seems to tackle this issue, i guess that means it is not a big deal after all.

[@OGLDEV]

I think that you can force your users to call SetRotation with a number that is smaller than 360. In most cases the user is you so just manage your rotations properly so you don't call SetRotation with crazy numbers. Then, if you call Rotate which accumulates the rotation angle you can check if the sum is greater than 360 and then subtract 360. The parameter to Rotate must also be < 360 so you can only move from N*360 to (N+1)*360 and in that case you don't need division. I have to say that I don't know if there is a popular solution to this problem.

[@onogrirwin]

I had some issues with M_PI being undefined... I got around them buy just copy pasting the value into the macros at the top of ogldev_math_3d.h. It works in the cloned tutorial project, but not in mine that's made from scratch, even tho I have followed the tutorials as closely as I can.

[@OGLDEV]

You on Windows, right? Which version of Visual Studio? I M_PI should be defined in cmath but maybe try to include math.h. I have some logic about it at the top of ogldev_math_3d.h. Maybe you just need to define _WIN64.

[@Vagabond_Hobbit]

just had the same issue, I added the code before #include line and it's fixed. (and why youtube still doesn't have a way to paste code...) #ifdef _WIN64 #ifndef _USE_MATH_DEFINES #define _USE_MATH_DEFINES #endif #include #else #include #endif

[@kaiweiyeo4279]

Hi Etay, Thanks for the tutorials. PROBLEM: I ran into a strange error C2065 'M_PI': undeclared identifier. I think there is a conflict over what is M_PI in corecrt_math_defines.h (Microsoft file). SOLUTION: The solution was quite simple. Just "#define M_PI 3.14159265358979323846" in ogldev_math_3d.h just above ToRadians(x)

[@OGLDEV]

I define _USE_MATH_DEFINES in the preprocessor config of every project which should solve this. For more details see learn.microsoft.com/en-us/cpp/c-runtime-library/math-constants?view=msvc-170 Perhaps you are building the 'release' build? I only maintain the 'debug' build.

[@mohamadlakees8318]

how can i get ogldev_math_3d.h

[@OGLDEV]

git clone github.com/emeiri/ogldev It is in the Include dir

[@mohamadlakees8318]

@@OGLDEV I found it ,but still not found " unistd.h"

[@OGLDEV]

unistd.h is part of the standard library. On Linux you need to include it with . On Windows it is not required and it should be wrapped with ifndef _WIN64. Notice the '