Camera/object shaking

This is a discussion on Camera/object shaking within the Game Programming forums, part of the General Programming Boards category; I've had the problem of the camera and/or object shaking the further away the camera/object is from the world origin. ...

  1. #1
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,596

    Camera/object shaking

    I've had the problem of the camera and/or object shaking the further away the camera/object is from the world origin. It only occurs after some type of yaw or pitch occurs. Accel, decel, and roll do not cause the shaking.

    At first I thought it was because of floating point round-off but after looking at the matrix dump from frame to frame in a file I do not think that is the issue.

    Here is a frame dump of the main player object. The object was hard-coded to yaw 1.0f * timeDelta radians during the dump - the delta from frame to frame was 16.666667 ms or 1.0f/60.0f or 60 FPS. The dashboard and object were shaking both in cockpit and object view during the dump. This dump is of the model matrix for the object. I don't see any anomalies that would cause this shaking to occur.

    You can clearly see the axis of rotation in the matrices and that the Y axis was not affected. In fact the matrix looks quite stable to me - moreso than I thought it would.

    Please look at the attached file and let me know what you think. The matrices are LH and the file is arranged:

    11 12 13 14
    21 22 23 24
    31 32 33 34
    41 42 43 44

    The object had a starting position of 65000.0f,65000.0f,65000.0f.
    Last edited by VirtualAce; 03-12-2011 at 10:41 AM.

  2. #2
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,189
    Excessive loss of precision due to overly large coordinates. Generally you should constrain your world coordinates within 1.0f to -1.0f and scale your objects accordingly. Remember, GPU's only use single precision. I'm guessing this is the problem, it could be a bad driver or card anomaly.
    Until you can build a working general purpose reprogrammable computer out of basic components from radio shack, you are not fit to call yourself a programmer in my presence. This is cwhizard, signing off.

  3. #3

    Join Date
    May 2005
    Posts
    1,041
    That's certainly a possibility, especially if your pilot console is what might otherwise be defined as four miles wide.

    What happens when you change the frame rate though?

    How are you actually integrating your orientation?
    I'm not immature, I'm refined in the opposite direction.

  4. #4
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,239
    Before blaming "large" coordinates (they have to be pretty freaking large to start encountering IEEE quantization noise) I would start by examining your use of any trigonometric functions. The standard trig functions don't do so well when their argument is outside the range 0..2*Pi. Sure, 4*Pi is mathematically the same as 2*Pi, but in practice not so much.

    If you are maintaining a rotation state by just adding and subtracting relative angles, you may be driving the total angle outside the range 0..2*Pi and getting poor results from the trig functions. The fact that the problem starts happening at large coordinates may just be because, by that time, sufficient angles have been added to get well outside the accurate range of the trig functions. Just a guess.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  5. #5
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,596
    What happens when you change the frame rate though?
    Nothing.

    How are you actually integrating your orientation?
    Simple Euler.

    F is the sum total of all forces on the object

    A = F / M
    V += A * dt;
    P += V * dt;

  6. #6
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,189
    Quote Originally Posted by brewbuck View Post
    Before blaming "large" coordinates (they have to be pretty freaking large to start encountering IEEE quantization noise) I would start by examining your use of any trigonometric functions. The standard trig functions don't do so well when their argument is outside the range 0..2*Pi. Sure, 4*Pi is mathematically the same as 2*Pi, but in practice not so much.
    Sorry, the engineer in me calls those coordinates : X, Y, Z, Yaw, Pitch, Roll, dX, dY, dZ, dU, dV, dW

    All 12 coordinates you need to define an arbitrary object in 4 dimensions.
    Last edited by abachler; 12-18-2009 at 01:16 AM.
    Until you can build a working general purpose reprogrammable computer out of basic components from radio shack, you are not fit to call yourself a programmer in my presence. This is cwhizard, signing off.

  7. #7
    Registered User
    Join Date
    Oct 2006
    Posts
    250
    Using Euler angles instead of quaternions per chance?

  8. #8
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,189
    Quote Originally Posted by MWAAAHAAA View Post
    Using Euler angles instead of quaternions per chance?
    Computer graphics don't generally use quaternions. The 4th dimension is time, not imaginary.
    You need 3 coordinates for position, 3 for facing, and 6 more for the delta (velocity/radial velocity).
    Last edited by abachler; 12-18-2009 at 05:20 AM.
    Until you can build a working general purpose reprogrammable computer out of basic components from radio shack, you are not fit to call yourself a programmer in my presence. This is cwhizard, signing off.

  9. #9
    Registered User
    Join Date
    Oct 2006
    Posts
    250
    Quote Originally Posted by abachler View Post
    Computer graphics don't generally use quaternions. The 4th dimension is time, not imaginary.
    You need 3 coordinates for position, 3 for facing, and 6 more for the delta (velocity/radial velocity).
    He needs some way to keep track of his current position/orientation, independent of the graphics layer, no? I am fully aware that OpenGL and co. use 4x4 transformation matrices internally to represent/specify object position/orientation.

  10. #10
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,189
    Quote Originally Posted by MWAAAHAAA View Post
    He needs some way to keep track of his current position/orientation, independent of the graphics layer, no? I am fully aware that OpenGL and co. use 4x4 transformation matrices internally to represent/specify object position/orientation.
    More specifically it requires at least 2 4x4 matrices to properly render an object and in practice it takes 3 to render multiple objects correctly, the 3rd being the camera, but i fail to see why you are even making this point as it is irrelevant to the requirement for 12 coordinates. You still have to keep those coordinates which are then put into the matrices in order to render the object.
    Until you can build a working general purpose reprogrammable computer out of basic components from radio shack, you are not fit to call yourself a programmer in my presence. This is cwhizard, signing off.

  11. #11
    Super Moderator VirtualAce's Avatar
    Join Date
    Aug 2001
    Posts
    9,596
    He needs some way to keep track of his current position/orientation, independent of the graphics layer, no? I am fully aware that OpenGL and co. use 4x4 transformation matrices internally to represent/specify object position/orientation.
    What?

    Each object has a world matrix that is computed by an orientation class that concatenates the indiv. matrices into a final world matrix. This matrix is then used to render the object. What do you mean by independent from the graphics layer? I'm using D3DXVECTOR3 which wraps D3DVECTOR and while it is independent from Direct3D Microsoft has been so kind as to put it into the D3DX library.

    It does take at least 3 matrices to render an object correctly in 3D. My coordinate system is using something similar to what abachler posted. I'm not using any trig functions for the basic orientation system so I'm not sure where that is coming from.

    In addition what I'm getting at here, and as evidenced by the frame by frame output in the file, is that there is no evidence of matrix creep or imprecision in 41, 42, and 43 of the matrix. This is the translation portion of a LH D3D matrix and it shows no issues from frame to frame.

    In order to shake like it is on my screen the 41, 42, and 43 values would have to bobble around 65000.0f pretty significantly and yet they are not moving at all in the file, on the screen, or in the debugger. So it makes me think I'm doing something goofy when extracting the right,up, and look vectors from an arbitrary 4x4 matrix.

  12. #12
    Malum in se abachler's Avatar
    Join Date
    Apr 2007
    Posts
    3,189
    Check the matrix values for the viewport. I'm just guessing but its worth looking at.
    Until you can build a working general purpose reprogrammable computer out of basic components from radio shack, you are not fit to call yourself a programmer in my presence. This is cwhizard, signing off.

Popular pages Recent additions subscribe to a feed

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21