I have a rather simple setup, a model at 0,0,0, with:
projection = glm::perspective(fov, aspectRatio, near, far);
model = glm::mat4(1.0);
I want a flexible camera, which is, from what I read the best described as FPS camera.
Now I am having:
glm::mat4 CameraMatrix = glm::lookAt(
glm::vec3(cameraPosition.X,cameraPosition.Y,cameraPosition.Z), // camera, in world space
glm::vec3(cameraTarget.X,cameraTarget.Y,cameraTarget.Z), // direction vector eye + Dir
glm::vec3(upVector.X,upVector.Y,upVector.Z)
);
very much as described here: http://www.opengl-tutorial.org/beginners-tutorials/tutorial-6-keyboard-and-mouse/
This is working out fine except one thing, mouse up and down does as intended, but left-right rotation the mouse makes the model rotating around cameraposition and not camera rotating around the model? Did I make something wrong?
My impression is that this requires at least some additional rotation and maybe translation to make it work correctly. If so, I am wondering why this seems to be mentioned nowhere. There are plenty of tutorials using lookat also if referring to "FPS camera" when I google for it. This confuses me a bit.
Now the examples around glm::lookat are rather poor and I read some stuff for gluLookAt in which I heard some voices that at least gluLookAt is no solution for such a task, does the same apply to glm::lookat? And if so, what's the right way to go? I am really not bound to glm:lookat in any way, it's just when I stumbled across it, I was like "HEY! Just what I was looking for" and it seems to be a clean and easy solution.
Maybe someone can shed some light on this and point me into the right direction or tutorial.
it appeared to be that one of my matrices was upside down, causing this problem.
The tutorial mentioned above was very helpful to find out. So if anyone stumbles across such an issue, it can be a simple math problem and indeed glm::lookAt does all I need.
Related
After reading on the coordinate systems in OpenGL, I figured to move the camera around the world I just need to translate the view coordinates. If I say use view = glm::translate(view, glm::vec3(0, 0, -50));, I'm translating the camera 50 units back (by translating the world 50 units forward). After thinking I had it figured out, I encounter LookAt function. I can't understand why I would need to use this function, if I just can move around my camera by translating and rotating the view. The whole thing is a bit hard to wrap the head around, so I'm sorry if this doesn't make much sense!
glm::LookAt or mat4x4_look_at of linmath.h or gluLookAt, and so on, are all just there for your (= the programmer's) convenience. That's all.
If you want to setup the view portion of the modelview transform with a different method, because it suits you better, then by all means you should to that then.
Currently I'm using WebGL for a school project, and am stuck on trying to keep an object perpendicular to the camera while allowing rotation of the rest of the scene.
I currently have a cube and other object on the canvas, and they're being successfully rotated using a quaternion and converting that to a rotation matrix. I would now like to add a simple square within the scene, but have it consistently perpendicular to the camera.
In thinking about this, I've considered an approach using multiple vertex shader programs for the different objects in the scene: 1 for handling the positioning of all objects in the scene that can be rotated, and another vertex shader corresponding to the square that I don't want rotated.
Though, I really don't know if this approach will work as expected, as I am still a novice at WebGL.
Would there be a better approach to this? I greatly apologize if there's a lack of info given, and can give any more info if needed. I've searched quite a bit for something involving this, but have hit a dead end.
Thank you!
If you want a more step by step tutorial: http://www.opengl-tutorial.org/intermediate-tutorials/billboards-particles/billboards/.
A slightly strange question, perhaps, but I have been brushing up on my DirectX and I've hit an odd problem. I recently finished my camera class and when I run the application to view a cube, I notice that the object being viewed isn't centered on the screen. I've double-checked the initialization variables and the vertex coordinates of the cube and they all seem to check out. I'm using a left-handed coordinate system, with the camera located at (0, 0, 10) and it's direction being (0, 0, -1). The cube itself is 6.0f wide, high and deep and centered at the origin. With all of these parameters, the edge between the two front facing sides of the cube should align perfectly with the center of the screen.
This is my result:
My question is not one that requires code to be posted, so I won't bore you with it until it is necessary. I've been poking at the code for some time and haven't found a possible source yet. My question is more of a theoretical one than anything else, to help me try and understand what is causing this. So, what possible causes could their be for this?
In case it is important, I also calculate my own view matrix, but I've double-checked that code and it seems to check out.
Thank you in advance,
Kevin Delval
The problem was related to rotations, not my matrix math.
Removing the sneaky rotation solved the problem.
Right now I'm panning by glRotating before rendering everything, and i'm moving the camera by gltranslating. I feel as if this is wrong since im essentially moving the scene, not the camera. What is the proper way to move the camera?
Thanks
Actually 'moving the scene around the camera' is the proper way in OpenGL.
This is due to the fact that OpenGL combines the view and model matrices into the modelview matrix. (look here for more details)
Obvious the lookat function (as mentioned above) is an easy way to move a (virtual) camera but i found that it doesn't work for OpenGL3.
I'd suggest to use the excellent glm library to setup the transformation matrices for OpenGL3.
Kind Regards,
Florian
Moving the scene and the camera is essentially the same thing. One being the negative of the other.
The usual way of implementing it is to have a camera class with absolute coordinates and direction, then you just put
glTranslate(-camera)
glRotate(-camera)
at the top in your display function.
gluLookAt is how you move the camera.
I'm learning some OpenGL game programing, and I'm stuck in how to implement so the camera follows the mousepointer. Like in a fps game you want to look where your mouse is pointing, but I can't find a nice solution to this while I'm moving. I was thinking of saving one matrix for the move, like walkking and strafing, while using quaternions to handle the rotation. Then make the quaternion to a rotationmatrix, load the identity for the modelview matrix and time this matrix with both matrixes.
There is ofcourse some problems with this, like which matrix we should use in the multiplication first, and the code will be ugly.
So I'm wondering if anyone have a good solution to solving this, so I don't have to find out which matrix to use first, and which gives cleaner code.
Store the camera's view details as a position vector, a view-vector and an up-vector (think of pointing with your thumb stuck out: your finger is the view-vector, and your thumb is the up-vector). Keep these vectors normalized and at 90 degrees to each other. You should be able to see that these three vectors are sufficient to represent any camera position and orientation.
You can use these vectors to transform world-coordinates to camera-coordinates:
Translate by -position;
Rotate around (up-vector 'cross' y-axis) by -(angle between up-vector and y-axis);
Rotate around up-vector by -(angle between view-vector and z-axis).
(I might have got some of my signs the wrong way around there).
You can transform these vectors as the user moves the mouse:
As the mouse moves sideways, rotate the view-vector around the up-vector (or rotate both view-vector and up-vector around y-axis, if you prefer).
As the mouse moves back/forwards, rotate both the view-vector and up-vector around (view-vector 'cross' up-vector).
I don't really have a solution for your problem, but i know the open-source 3d engine Irrlicht has a FPS camera that does exactly what you're looking for and, usually, it has a well-documented source.
You could try looking at how the FPS camera is implemented in Irrlicht or you could even use Irrlicht itself for your project; i used it for a couple of mine when i was in college and it always worked like a charm :)