Back to General and Gameplay Programming

OpenGL, Translating a Sphere

Joshua Eirman · 2019-07-14T17:53:06

I am rotating a world like a FPS and need a sphere to move opposite to the camera so that the effect is it stays put. Here is the ball moving wrongly with the rotation: https://www.youtube.com/watch?v=ksNt3W_p5u8 and here is the function that changes the camera vectors with my try that didn't work: void Camera::updateCameraVectors(void) { // Calculate the new Front vector glm::vec3 front; front.x = cos(glm::radians(this->yaw)) * cos(glm::radians(this->pitch)); front.y = sin(glm::radians(this->pitch)); front.z = sin(glm::radians(this->yaw)) * cos(glm::radians(this->pitch)); glm::vec3 temp = this->front; this->front = glm::normalize(front); // Also re-calculate the Right and Up vector this->right = glm::normalize(glm::cross(this->front, this->worldUp)); // Normalize the vectors, because their length gets closer to 0 the more you look up or down which results in slower movement. this->up = glm::normalize(glm::cross(this->right, this->front)); //this didn't work: //ball.xadj = ball.xadj + front.x; //ball.zadj = ball.zadj - front.z; } and this is for changing the world with the mouse: void Camera::ProcessMouseMovement(GLfloat xOffset, GLfloat yOffset, GLboolean constrainPitch) { xOffset *= this->mouseSensitivity; yOffset *= this->mouseSensitivity; this->yaw += xOffset; this->pitch += yOffset; // Make sure that when pitch is out of bounds, screen doesn't get flipped if (constrainPitch) { if (this->pitch > 89.0f) { this->pitch = 89.0f; } if (this->pitch < -89.0f) { this->pitch = -89.0f; } } // Update Front, Right and Up Vectors using the updated Eular angles this->updateCameraVectors(); } and to get the view matrix: glm::mat4 Camera::GetViewMatrix(void) { return glm::lookAt(this->position, this->position + this->front, this->up); } lastly, the translate: ball = glm::translate(ball, glm::vec3(c_mycamera.ball.xadj, 0.0f, c_mycamera.ball.zadj)); So, how do I get the exactly correct amount for translating the sphere over and over again as the world rotates? This has been my ongoing project for some time (thanks,) Josheir

General and Gameplay Programming Programming C++

Started by Josheir July 07, 2019 11:23 PM

32 comments, last by Josheir 5 years, 5 months ago

Zakwayda

2,389

July 09, 2019 07:04 PM

45 minutes ago, Josheir said:

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

If you're asking whether you'd use the same view transform for both the terrain and the ball, the answer is probably yes.

In a simple environment, typically there will be a single projection transform and a single view transform. Sometimes you can have multiple projection/view transforms, e.g. for picture-in-picture effects, UI elements, specialized first-person elements like a player's hands or held items, etc. But in a typical simple scene you'd have one projection transform, one view transform, and N world transforms, for some arbitrary value N. (I think this has all been touched on in various forms by others previously.)

I don't know if this'll help, but here's an attempt at a graph showing what we're talking about:


                projection transform
                          |
                   view transform
                          |
-----------------------------------------------------
      |                   |                  |
world transform     world transform   world transform
(e.g. terrain)        (e.g. ball)          (etc.)

In practice the world transforms can be arbitrary hierarchies, but we're just keeping it simple here.

Your focus in this thread seems to be on how to come up with an appropriate view transform, and there have been various suggestions made about that.

As has been pointed out, a view transform is typically the inverse of a world transform. It's the inverse because its purpose is not to transform geometry from local to world space, but rather to transform geometry from world to local space (that is, to camera space). So-called 'look at' functions hide these details from you in that they build a world-to-local transform for you given (usually) a position, a target, and reference up vector.

I would say that using a 'look at' function would probably be the easiest way for you to build an appropriate view transform. You know what the world up vector is, and you know what the target is (the ball position). That leaves only the camera position that you need to compute. (This isn't the only way to go about it, but I think it's a fairly straightforward way.)

I can't tell you exactly how to compute the camera position because at this point I'm still not entirely clear on what behavior you want. There have been various suggestions though, so I suspect the answer is somewhere in this thread. In any case, whatever behavior you're after, computing the camera position should only require a little vector math and/or trig (for the basic behavior at least).

soerensen3

July 09, 2019 08:11 PM

1 hour ago, Green_Baron said:

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()).

It's one or the other. You can use either glm::lookat() to calculate your view matrix or in case you already have a world matrix for your camera object you can obtain a view matrix by inversing the world matrix.

@Josheir Have a look at the picture below. It is a visual representation of a world matrix and above you see the mathematical representation. The location is in the 4th column of the matrix. You can see colored axes (X=R, Y=G, Z=B). These can be found in the columns 1 to 3. As stated already by @Zakwayda the world matrix can be used to transform objects from model (a.k.a. object space) to world space. On the right side you see the cube in object space. Please note that the cube isn't rotated and centered at 0,0,0. By calculating the inverse of the above matrix you can convert from world to object space which is exactly what the view matrix does. The view matrix is related to your camera and nothing else so there is no view matrix for your cube. However you can still calculate the inverse matrix only that it is not called view matrix but object matrix.