About the linked Demo
The linked demo uses euler angles, has a locked target on the center of the scene, and you drag left aqnd right to move the first euler angle, or up and down right to move the second one. The third euler angle is not controlled and remains where it starts.
It is geographic coordinates: the first angle is the rotation on the horizontal axis (Longitude), and second angle is the angular elevation from that plane (Latitude). The first angle can do a full rotation, while the second is limited to minus one quarter rotation to plus one quarter rotation. You can confirm on the demo.
To implement it, store the two angles I mention above in varialbes, update them based on the drag gesture, and use them to compute the position of the camera (and the up vector too, given the way you represent your camera).
A virtual camera has
orientation and a
viewing volume (usually a perspective projection, can be orthogonal, skwed or something else).
At the end a position and orientation becomes a matrix transformation.
I will not be talking about the viewing volume.
What you have is a lookat matrix. It is a valid transformation matrix.
However, I am not a fan of it, because it sticks you to the vectors (
eye). It gives you the idea of modifying the vectors directly, which is error prone. For instance, you may end up with a combination of
lookat that does not make sense. We always need to move
We can acomplish that by treating them as a matrix instead of treating them as vectors. I am suggesting to forget about
eye. I am suggesting to not treat those components of the matrix as vector and to not operate on them directly. Use them as a matrix. Or rahter, I should say, just as a matrix.
Addendum: To move the camera, you can create a translation matrix and apply it to the one of the camera. Similarly to rotate it. However to replicate the demo, recompute the the matrix transformation of the camera each time the user drags.
Note: Whatever the vectors are columns or rows is convention. OpenGL (which GLFW uses internally) only cares about the order in memory. This can also be a source of confusion. In fact, I didn't think you had it right, just because last time I was working with them, I was considering them rows.
There are many models for camera control. There is the static camera that does nothing. The fixed camera that does not move but changes orientation to follow the action. There are cameras that follow the action at a fixed distance. There are variants that are controlled by the player. There are scripted sequences where the camera follows a predefined trajectory...
A common idea is to have the camera follow a object that is affected by physics and collisions (that is effectively what you would do in a FPS). However, if this is physic object is on itself separate from the avatar (for example a third person camera), it also means that the camera can bumb or even get stuck due to collisions. And we do not want that... we would use ray cast checks to anticipate and avoid the collisions. And we want this collision avoidance to be smooth and to keep the action in view.
There is then the problem of objects obscuring the view of the avatar. Some games will have those objects appear translucid, or will render silhouettes, etc.
Futhermore, I have been saying "the action", because the camera may not only be following the player's avatar. For instance you may offset it to show points of interest or to keep nearby enemies in frame.
Sorry, I do not have any books to suggest. Hopefully the presentation "50 Game Camera Mistakes" can help you.
What we have in the linked demo is an orbit camera. As I said at the start, it is controlled by euler angles. I will be refering to the point around which the camera orbits as the "target".
Start by declaring your first and second euler angles. Then each time the player drags, you increment the euler angles accordingly to the drag distance, horizontally and vertically respectively. Note that you can do both movements in the same drag gesture.
The position of the camera will be an initial position that you rotate by the euler angles... And the orientation of the camara will be dictated by that same rotation.
Note: I am assuming that you pick an starting position and orientation that is at desired distance from the target and looking at it. Then all you need to do is to get the correct rotation from the euler angles.
To get that rotation, your library has an utility to create a rotation transformation over one of the main axis. Use it to create two rotation matrix (one for each angle) and combine them (multiply them together).
Note: Remember that the order matters in matrix multiplication.
Again, forget about