I have written some code to rotate the camera around the (0, 0, 0) position (scene’s origin) but I think something is wrong since I didn’t get what I’m expecting.
this is my code;
hi Idriss,
You use glm::lookAt() … why not some of the other glm-functions that does the details that you setup with std? It could make it easier to debug.
Doesn’t this seem silly to you:
It would be a good idea to be specific about what you expect, but also about what you achtually get.
I want to move the camera around my model (which is in the 0,0,0 position). In other terms, I want to rotate the camera around the model. i think glm::lookAt is the most suited in this example. cameraFront = glm::normalize(cameraPos - glm::vec3(0.0, 0.0, 0.0)); I got this from this: https://learnopengl.com/Getting-started/Camera but I’m stuck, I cannot rotate the camera.
So, the setup gives you an image that does not move? or do you get a black screen where you achtually does not get any feedback on what your code is doing?
Idriss;
cameraFront = glm::normalize(cameraPos - glm::vec3(0.0, 0.0, 0.0));
is equel to
cameraFront = glm::normalize(cameraPos);
It worries me, that you do not seem to look through this.
Are yo sure that you read the tutorial properly?
LookAt() takes coordinates of what you look at as input. That would be 0,0,0 … soo, what’s happening?
When I rotate the mouse, I can’t see my model anymore. yes you’re right about the equality but I can’t figure out how to use it accordingly to this tutorial. maybe you can give a hint or something so I can get the right rotation
If you’re positioning the camera relative to the object, don’t use lookAt, use translate and rotate. lookAt is for the case where the camera and target are positioned independently of each other.
Also: too many tutorials try to mimic legacy OpenGL idioms. When it comes to placing a camera in modern OpenGL, you should construct a matrix as if the camera was an object, then invert the matrix to get the “view” transformation. Legacy OpenGL didn’t have any mechanism to invert a matrix, so the solution was to construct the inverse from the inverses of the individual transformations applied in reverse order: (ABC)-1 = C-1B-1A-1.
Can you make
cout <<
of the cameraPos value ?
Is your model 3d?, a box?
How does the bounding-box/approx values of model compare to cameraPos value?
I don’t see why the simple
glm::LookAt(cameraPos , vec3(0,0,0), vec3(0,1,0) ) does not produce a view of the model unless the cameraPos is within the model-volume itself
@CarstenT, yes it’s a 3D model (it’s cesium man). the simple glm::LookAt(cameraPos, vec3(0,0,0), vec3(0,1,0)) works fine for translation but the rotation is a combination of translation and where the camera is pointing (which in my case the cameraFront), I have already debug the code and the values of cameraPos seem to be correct for me
Any matrix which can be generated with lookAt can also be generated using some combination of rotate and translate. The main difference is that lookAt constructs the rotation matrix from vectors rather than angles. If the vectors you’re passing to lookAt are generated by rotation, you may as well just use rotate.
In your original post, the problem is that cameraPos and cameraFront are identical (you’re subtracting a zero vector from cameraPos to get cameraFront) and so the “forward” vector (which is just their difference) is zero which leaves the orientation undefined (you’ll probably end up with a vector of NaNs when lookAt tries to normalise the vector).
@GClements, yes you’re right, I got a NaN value yesterday. But, there’s no solution to use lookAt properly? I can’t work with rotate and translate or I’d rather not working with rotate and translate
@Idriss,
You’ve presented us with code that handles input that you turn into an angle that you build a xz-plane vector from with approx 20 pix radius.
This will rotate the ‘camera’ if you use the LookAt() as perscribed.
so, what’s the problem?
You just stupified me.
Or moved the goal-posts without telling us where to.
If you want to controle individual input to cameraPosition and cameraDirection, then have a ponder on a totally new approach and get a gist on the link “input-confusion”