// before this the x and z components of the view point maybe updated from
// the keyboard. If that's relevant tell me and I'll add the code!
void Player::rotate(const double xMove, const double yMove, const Camera &playerCam){
// Get the view vector
Vector3d vVector = _wantView - playerCam.getPosition();
_wantView.y += yMove;
_wantView.x = (_wantPosition.x
+ cos(xMove) * vVector.x
- sin(xMove) * vVector.z);
_wantView.z = (_wantPosition.z
+ sin(xMove) * vVector.x
+ cos(xMove) * vVector.z);
}
My camera that slowly stops working.
Author
I'm using OpenGL for a simple FPS and it's basically functional. I hacked in movement at the start and now I'm coming back and trying to refine it. This is my first 3d attempt.
When you start the game you can use the mouse to look around, like any normal FPS game. If you start to run about a bit, you slowly can't look up or down as easily, and finally not at all. The looking to your left or right though works fine!
I'm using gluLookAt and updating the view point each frame. xMove and yMove are the number of pixels the mouse cursor has been moved from the center of the screen, then multiplied by the time elapsed for the current frame.
Now, it's obviously wrong - but why would it work at the start and only gradually die?
Thanks to any one who can give me a hand.
It's usually not a good idea to have one view vector that you continually update, since over time the floating-point inaccuracy of each calculation will accumulate and eventually the view vector is either just wrong or even degenerate.
A better approach would be to keep a set of Euler angles, and update the angles directly as the player moves the mouse (since x-movement corresponds directly to yaw, as y-movement corresponds to pitch). Then you can use spherical coordinates to generate the view vector based on pitch and yaw, and lastly gluLookAt to get the camera matrix.
If you also want the player's camera to roll, then you'll have to use full 3D rotation math to utilize all three Euler angles, but for pitch and yaw alone this method works well.
A better approach would be to keep a set of Euler angles, and update the angles directly as the player moves the mouse (since x-movement corresponds directly to yaw, as y-movement corresponds to pitch). Then you can use spherical coordinates to generate the view vector based on pitch and yaw, and lastly gluLookAt to get the camera matrix.
If you also want the player's camera to roll, then you'll have to use full 3D rotation math to utilize all three Euler angles, but for pitch and yaw alone this method works well.
I dont see any particular problem with using a view vector like you are, and similar approaches will be inevitable if you plan on upgrading to a full 3d (flightsim) type camera.
To deal with the cumulative floating point innacuracy simply Normalize your vector after each update.
To deal with the cumulative floating point innacuracy simply Normalize your vector after each update.
Author
Cheers for that! Normalizing it worked great, it was just rounding error messing it up.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
