Fixed timestep and interpolated movement

[cobolt_dink]

My game logic is locked at 60 FPS which means the Bullet update is 60 FPS and the rendering in uncapped. When using the motion state what is the proper way to get the interpolated movement between frames?

This way is very jerky and has a lot of ghosting

Code: Select all

btTransform trans;
body->getMotionState()->getWorldTransform(trans)

This way is better but is still jerky at times

Code: Select all

btTransform trans;
btDefaultMotionState *myMotionState = (btDefaultMotionState *)body->getMotionState();
trans = myMotionState->m_graphicsWorldTrans;

Game is rendering at 800-1000 FPS so I know the logic is getting called in a timely matter.

[keely]

I think I have the same issue with interpolation. These might help (I'm going to try myself later today):

http://liquidrockgames.blogspot.com/200 ... ndent.html
http://gafferongames.com/game-physics/f ... -timestep/

[cobolt_dink]

Any word of that patch being done? Or better yet having it put in the upcoming 2.75 release? I'm sure we aren't the only two people to have this problem. How has everybody else dealt with the interpolation issue with Bullet?

[Erwin Coumans]

This has already been implemented in Bullet for a long while, using the motion states.

You need to call the stepSimulation, even for non-simulating frames, to get the interpolation up-to-date.
Just call stepSimulation with a single argument, don't provide second or third:

Code: Select all

stepSimulation(deltaTime);

And call stepSimulation with small delta-times at the graphics framerate: the internal physics timestep stays 60hertz, but the motion state is automatically interpolated for the graphics. Just check out the implementation inside btDiscreteDynamicsWorld::stepSimulation.

Hope this helps,
Erwin

[cobolt_dink]

So for smooth movement stepSimulation() needs to be called every graphics update and not just the fixed timestep of the game logic? I guess I thought the bodies were doing the interlopation themselves. Guess that makes sense, when updating the game and rendering every frame there is none of the jerkiness.

[keely]

And call stepSimulation with small delta-times at the graphics framerate: the internal physics timestep stays 60hertz, but the motion state is automatically interpolated for the graphics. Just check out the implementation inside btDiscreteDynamicsWorld::stepSimulation.

I just have JBullet source (based on 2.70 I think). I tried to figure out what kind of interpolation/timing it uses but could not get definitive answer yet. I know this is not the right place for JBullet issues though, and I will post my "findings" about my strange jitter/jerkiness in the JBullet-specific thread later on. Maybe get jezek2 to look at it if I'm lucky enough.

There is one thing I'd like to know about the Bullet in general. Does it extrapolate or interpolate?

If we have two known states A and B, where A.time=0 and B.time=1. A and B are NOT interpolated/extrapolated, but 100% accurate simulations. We are rendering a frame at currentTime=1.75 and have just called the stepSimulation correctly to have it interpolate smooth state for our currentTime. Does the Bullet:

a) use state B and extrapolate 0.75 ticks into the unknown future
b) interpolate a point between A and B with something like interpolatedState = A * 0.25 + B * 0.75

The article I linked was claiming (at march 2009), that bullet does the "method a", which could make it jerky at times. Which one is it and since what version?

[Erwin Coumans]

Bullet interpolates between two known simulation frames A and A+1 (call this B).

It would be good to get the patch from Lf3T-Hn4D, and see what is happening in his case.
Thanks,
Erwin

[keely]

Bullet interpolates between two known simulation frames A and A+1 (call this B).

Thanks for the quick reply! This certainly explains why I'm get equal jitter when I do interpolation between A and A+1 myself vs. reading from the motionstate. I was just doing the same thing that Bullet does.