# Camerabug at huge floating point values

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

## Recommended Posts

Hi, I have written a first person camera class which contains an at, eye and up vector. eye is the current cam position and at the point where the cam is looking at. Moreover at is always one unit away from eye. Everything works perfect if I fly around the world origin (0,0,0) (and thus the floating point values for eye and at are small) but if I fly away from the origin (for example eye = (50000, 0, 0)) and at = (50000, 0, 1)) then translation still works but rotating the camera is totally broken. This is my code for the rotation about the y-Axis (if the user spins the head):
void FreeCamera::yaw(double deltaX){
D3DXVECTOR3 dir = at - eye;

D3DXMATRIX rotY;
D3DXVec3TransformCoord(&dir, &dir, &rotY);
this->at = eye + dir;
D3DXVec3TransformCoord(&up, &up, &rotY);
D3DXVec3TransformCoord(&right, &right, &rotY);
}

So all I do is calculating a direction vector from eye to at, rotate this vector about the world y-axis and get the new at point by adding eye + dir. At the end I rotate the up and right (vector orthogonal to eye-at and up) about the world y-Axis. By the way: ALL my camera variables (deltaX, rotationSpeed and so an) are DOUBLES and not floats. I have the assumption that floating point precision could be my problem. But I cant prevent the user to fly around in my huge world. I think this is a common problem and hope, someone has ideas what I could do against this problem. Thanks

##### Share on other sites
You're definitely just having problems with precision. 50,000 is huge for a 32-bit float (your doubles are bound to be handled as floats, since by default D3D sets the FPU to single precision round-to-nearest mode).

##### Share on other sites
You might be able to make it work with those big coordinates. The calculation that has the most issues with precision in that code is the first line: D3DXVECTOR3 dir = at - eye;

The problem is that if the values of at and eye are close then the subtraction will lose you most of the accuracy of the value.

If you can store a lookat direction vector as opposed to a position then it should work a lot better.

Also note that when building the three vectors (forward, up and right) that it's usually better to compute one of them as the cross product of the other two to make sure they stay at right angles to each other.