Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
2 hours ago, soerensen3 said:Then for rotating your camera all you need is yaw because the camera is automatically rotated with the model already.
How's that, can this be explained easily?
Thank you everyone for the help I'm still re-reading/studying all the posts and researching too.
Josheir
On 7/7/2019 at 7:23 PM, Josheir said:this->position + this->front
If you position the sphere at that position (camera settings for glm::lookat) it will be right in front of you and move as you move.
Because when you apply the inverse of the model transform of your sphere, it has always the same rotation as your sphere. You can of course also do it the other way around and apply the inverse rotation of your camera to the sphere. I thought the sphere is supposed to be the ball so I thought this makes more sense but it really doesn't matter.
However an object that always has the same rotation as your camera will appear to be not rotating from the perspective of your camera. Have a look at the attached screenshots from blender. The cube has the same z rotation as the camera. Please note that in blender the up vector is Z not Y so the rotation is around Z. The X rotation (yaw Pitch) however is different which is why you can see the top of the cube as well. Also the location is different for both objects. The location is in world space.
However I forget to mention that all transformation you apply to your camera needs to be inverse, so the yaw and translate part need to be inversed too. So it is better to inverse once after the multiplication.
pseudo code:
inv_view = mdl_sphere * cam_rotation * cam_translate
view = -inv_view
Edit: Also the rotation you need is pitch not yaw (X-Axis). Sorry I can never remember the names correctly!
So, how many view perspectives are there and what are they if not mentioned by you yet? Could you elaborate about these?
You can have a model transformation for the camera. You position and rotate it (in the world) just like any other object in your game. The view transformation is the opposite of that camera model transformation. Instead of positioning it in the world, it moves the camera (not really, it moves everything else) and rotates it at 0,0,0 down -z.
For getting all the math down in your head I would recommend not using a view or projection matrix except for rendering. Do everything on the CPU side in world space. So M matrix (to get to the world space) on CPU and send V and P matrices to GPU with shaders. Don't do any game math or logic in the View space and especially not in the Projection space. Later, you can do faster calculations in View space.
The learnopengl.com tutorial has reasonable chapters on the spaces and transformations.
You could begin with simply moving your camera with an offset from your model, like lookat( targetpos + offset, targetpos - ( targetpos + offset ), up ). So the camera will follow your object with the offset, looking at it. Now the problem is still, when the object turns, your camera will remain where it is, which is not what you want, you ant your cam to turn in the x/z plane (but not in y). Which makes it sort of a restricted orbiting cam. To follow turns you can either use what @soerensen3 suggested, or use trigonometry similar to the one you use for fp or orbiting cams. I leave it to you, it is really not magical ?
53 minutes ago, fleabay said:
For getting all the math down in your head I would recommend not using a view or projection matrix except for rendering. Do everything on the CPU side in world space.
When using WORLD to calculate camera there are still two objects that are being viewed. How does the terrain and the ball both get viewed when they have different world-like cameras?
Who says they do ? They don't. They may have different model matrices, but the view- and perspective matrix are the same. @fleabay recommended to do everything in world coordinates (for now), to avoid having to switch around mentally between the coordinate systems.
I kindly ask to doublecheck the tutorials for example on learnopengl.com, or the latest Red and Blue book on OpenGL.
I hope a make no mistake now, this is the principle:
1. place objects in the world by applying rotation and transform to them. This is done with the model matrix for each object differently or grouped or whatever. One can place millions of objects this way. The model-transform puts the objects into world space.
2. calculate (in world coords) a camera position, view direction and up vector. The camera can perform any gymnastics one likes, using trigonometry, inverse matrices, offsets, or simply put into place. After the calculation of the camera position, view and up vectors, calculate the view matrix (glm::lookat()).
3. create the projection matrix from viewport size and near/far plane (glm::perspective()).
4. multiply proj and view and model matrix together to obtain all positions in camera space. The number of objects is banana, they are all just positions in world-space. This step is usually/frequently/partly done in a vertex shader.
You are now pondering over point 2. How to calc the position of the camera.
Hope that was not totally incorrect ?
