Camera/object shaking

**VirtualAce** · 12-15-2009

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.

**abachler** · 12-15-2009

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.

**BobMcGee123** · 12-17-2009

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?

**brewbuck** · 12-17-2009

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.

**VirtualAce** · 12-18-2009

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;

**abachler** · 12-18-2009

Originally Posted by brewbuck

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.

**MWAAAHAAA** · 12-18-2009

Using Euler angles instead of quaternions per chance?

**abachler** · 12-18-2009

Originally Posted by MWAAAHAAA

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

**MWAAAHAAA** · 12-18-2009

Originally Posted by abachler

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.

**abachler** · 12-18-2009

Originally Posted by MWAAAHAAA

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.

**VirtualAce** · 12-18-2009

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.

**abachler** · 12-18-2009

Check the matrix values for the viewport. I'm just guessing but its worth looking at.

Thread: Camera/object shaking

Thread Tools

Search Thread

Display

Camera/object shaking