Jump to content
  • Advertisement
Sign in to follow this  

My camera that slowly stops working.

This topic is 4335 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

// 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);

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.

Share this post

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

Share this post

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

Share this post

Link to post
Share on other sites
Sign in to follow this  

  • 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!