Archived

This topic is now archived and is closed to further replies.

Camera Jitter

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

Recommended Posts

When tracking a mesh object with the camera, it seems to "hop" around. If I don''t move the camera, movement is very smooth. If I move the camera, the moving object acts like it''s trying to be in two places simultaneously. The object and camera are panning along the X and Y axes, and Z is constant. What sorts of things can cause this behavior? I have no idea where to even start right now.

Share on other sites
I''d also like to add that I HAVE read about precision problems, but that this happens very close to the origin as well. I''ve modified it so that the object being tracked stays at the origin, while the rest of the world moves. The object being tracked no longer shakes...but the entire world does, in concert.

Share on other sites
Could you post some code?

Share on other sites
Not easily...it''s spread around many classes at the moment. I can provide little structural info, though.

It is a space sim, locked in an overhead view. Z_NEAR is 1.0, Z_FAR is 5000.0, but setting this to 100.0 (or lower) makes no difference.

Each model has a D3DVECTOR for it''s "real" position, a D3DVECTORD for its position (a copy of D3DVECTOR, but with doubles), and a D3DVECTORD for it''s movement vector, which contains X and Y travel distance per second.

The way the translation is calculated is roughly:

REAL POSITION = ( float )
(POSITION +
FRACTION OF MOVEMENT -
TRACKING OBJECT POSITION)

So everything up to the actual translation is done with doubles, then dropped to float. FPU_PRESERVE is on.

The tracked object (player''s ship) is locked in the center of the screen. The world moves reasonably well, but every now and then "hops" a pixel or so.

I CAN actually post some code, but it''s a lot to wade through at the moment, especially since I''m probably just doing something obviously wrong.

Share on other sites
You have to think your camera as a physical object. In real world movement is usually continuous.

What im trying to say is that your camera should have a little inertia like property. So when you attach your camera to obj your camera will try to follow it in smooth & continuous way. Because the frequency of jitters is greatly reduced by this method, it acts like suspension of your car.

[edited by - DirectxXx on March 8, 2004 3:00:49 PM]

Share on other sites
Actually, the camera is fixed, but yeah, mathematically it''s moving right long. I''m using time-based movement, and the numbers coming out look good. Should be nice and smooth. I even coded it to follow in a delayed spline to smooth it out, but that made no difference at all (in this case I was actually moving the camera, "chasing" after the ship...and the ship was shaking horribly).

Share on other sites
Well, this just gets more interesting all the time.

In my efforts to track this down, I commented out the code that actually computes the time-based animation, as well as the actual rendering code. Now I have a tight loop of (pseudo-code):

Do   Begin Scene   Calculate and dump ms since last frame (using timeGetTime)   End Scene   DoEvents()Loop

Guess I should mention that this is in VB6.

Runs pretty quick (doing nothing). The ms times per frame dump like this:

7 8 8 6 7 10 75 2 2 1 1 3 8 6 8

The 10 to 3 are curious, and pop up every quarter to half second or so.

If I add a Sleep(5) in there somewhere (anywhere), it comes out like this:

19 18 19 40 18 18 19 18 27 20 19 18 1 18 19

Better, but still wrong. Something''s chewing up cycles, but what and where? Should I be setting the app priority?

Share on other sites
I hate to bump this up, but I hate being lost even more.

Could these numbers be the result of using timeGetTime? I don''t think so, since I''ve also used QueryPerformanceCounter and GetTickCount, with the same results.

Share on other sites
I don''t think the problem directly relates to timing accuracy.

You should sample your timing, so one bad time frame won''t cause hiccups. Hard drive/CPU activity will cause timing hiccups, which is unavoidable.

Share on other sites
maybe, you shoudl try using the average of the last 3 or 5 or 10 frame times instead of the single last frame. This will definately smooth it out some... I''m not sure if you will get other unwanted side-effects though. SOunds like ti would be worth a try in any case

Dwiel

Find out about my diy LCD projector and programming projects!

• 9
• 23
• 10
• 19