Jump to content
  • Advertisement
Josheir

C++ OpenGL, Translating a Sphere

Recommended Posts

Posted (edited)
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

Edited by Josheir

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
Posted (edited)

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!

Screenshot from 2019-07-09 09-11-33.png

Screenshot from 2019-07-09 09-09-49.png

Edited by soerensen3

Share this post


Link to post
Share on other sites
Posted (edited)

So, how many view perspectives are there and what are they if not  mentioned by you yet?  Could you elaborate about these?

 

 

Edited by Josheir

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites
Posted (edited)

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 😉

Edited by Green_Baron
Here's the missing w: 'w'

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
Posted (edited)

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 🙂

Edited by Green_Baron

Share this post


Link to post
Share on other sites

So, the view for the ball is determined and used for the previous terrain model too?

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!