When / where to get accurate node transform and elapsed time, eliminate jitter?

[ataylor]

Our application allows recording and playback of a simulated vehicle. While the user is driving the vehicle, code grabs the vehicle's world transform and an associated timestamp. A series of these transforms & timestamps are saved to a file. User can then load this file and watch a recording playback. This is all working at a fundamental level, but there is sometimes a problem with jitter and I would like to eliminate that jitter.

 

Graphics frame rate in our application is not always perfectly stable. Recording jitter errors are most noticeable when there is this frame rate instability during the recording process. I suspect this is a result of the method & timing of our recording code.

 

Sorry, I cannot currently share a small reproduction scene. The relevant code is complex and heavily tied into our overall application, and I'm afraid I do not currently have the resources to split it out for a demo at this time.

 

My overall questions are: Where is the appropriate place to grab the vehicle node's transform (update/render/flush)? And what should we use to determine an appropriate timestamp? Our current implementation accumulates time from Unigine::Physics::get()->getIFps() inside flush tick, while grabbing node transform inside update tick. 

 

Thanks for any help. I hope the above is understandable.

[ded]

Hi ataylor,

 

flush() has a fixed framerate so it is better to grab node's transformation there.

It perhaps will even make unnecessary to record timestamps, knowing physics FPS will be enough for correct playback calculations.

 

Accumulating time from Unigine::Physics::get()->getIFps() for timestamps seems the best option for me.

Maybe using Unigine::Game()::get()->getTime() will provide adequate results too.

 

The source of the jitter is also may be hidden in the way you interpolate a node's transformation at playback.

Consider storing node's transformation as Vec3 for position and quat for rotation (I bet scale doesn't change and can be omitted).

Usage of quaternions may fix the jitter.

 

I hope this is of any help.

[ataylor]

Thanks Maxim. I mainly wanted to verify I wasn't doing something completely wrong within the intended design of Unigine engine.

 

It seems our current implementation as I described above may already be the best approach. We corrected some other related issues within our application and the issue of jitter is almost unnoticeable.

 

By the way, our physics fps is actually much higher than you may expect -- as high as 120FPS, much faster than our typical graphics frame rate. Grabbing node transform in flush() means the node may not have moved since last flush(). Torques and forces will have been added to a RigidBody but they may not yet have been applied if flush() is called twice in a row before update(), so it seems best to grab transform in update()