Interpolation

[LtJax]

Hello!

Right now, bullet uses extrapolation exclusively to blend between actual simulation steps. However, some applications (such as mine) might require interpolation instead. While extrapolation is more responsive in a graphical environment, it can only be done on the position/orientation. Interpolation enables blending between other, possibly application defined, values as well. For example, velocity might be very useful for algorithms that have to take the screen-space velocity into account. User-defined values might be colors or other more sophisticated animation parameters.
After some investigation, it does not seem to be possible to layer this on top of bullet in an efficient and transparent manner. To efficiently support this, the MotionState and the general updating code would have to be reworked. Are there any plans to include this or similar features into bullet?
Whatever the case, I'd be more than glad to help out on the issue. I could investigate possible ways to cleanly integrate this with the existing design, and possibly even generate a patch that implements this.

Thanks,
Marius

[steven.hutheir]

Hi,

Right now, bullet uses extrapolation exclusively..

Could you please explain why do you think Bullet uses only "extrapolation"?

While extrapolation is more responsive in a graphical environment..

Could you please explain what do you mean by "responsive"?

After some investigation, it does not seem to be possible to layer this on top of bullet in an efficient and transparent manner.

Could you tell us more about your investigation and what turned out to be a problem?


What is the special circumstance in your application that requires interpolation, what is the problem and what is the expected result after?


Steven

[LtJax]

Could you please explain why do you think Bullet uses only "extrapolation"?

Well, it's not technically correct to say it uses it exclusively, but it uses it exclusively to blend between frames, *if* you use the MotionState API. Otherwise it doesn't do any blending.
After someone on IRC mentioned that bullet uses "forward interpolation", which is just a really awkward name for extrapolation, I read the sourcecode, specifically for btDiscreteDynamicsWorld and btRigitBody. The function is question is btDiscreteDynamicsWorld::synchronizeMotionStates().

Could you please explain what do you mean by "responsive"?

Changes to the position and orientation of the body are transferred to the "graphical entity" one step earlier than with interpolation. Hence, the user will experience a faster response to his action, even tho only by one frame (which is negligible for me, but might be nice for others).

After some investigation, it does not seem to be possible to layer this on top of bullet in an efficient and transparent manner.

Could you tell us more about your investigation and what turned out to be a problem?

What is the special circumstance in your application that requires interpolation, what is the problem and what is the expected result after?

Yes and no. Basically, the problem varies on the way this is integrated. I'll just list a few points here.

• There is no convenient way to read out the time between frames from btDiscreteDynamicsWorld (m_localTime). It is *possible* by deriving your own class from it, as it is only protected. This is needed if you want to implement your own interpolation.
• A mostly non-intrusive way to implement your own interpolation would be to 'disable' extrapolation. Currently, this can be done by not using motion states.
• If motion states are not used, you need to loop through all bodies and check for changes manually. While motion states currently basically do the same, they 'could' maintain a dirty flag (and comment from the source indicate that this is planned) and only send updates when needed.
• A nice way to integrate interpolation would be to use the existing motion-state api, and add a switch to disable the extrapolation, and guarantee that the motion state is only updated once per internal step. That way, one could read out additional data from the body or the user entity by overiding setWorldTransform in btMotionState. This would require some changes to btDiscreteDynamicsWorld::stepSimulation, as well as btDiscreteDynamicsWorld::synchronizeMotionStates (or possible a replacement for the latter), along with a get function for m_localTime.

Right now I need interpolation for the velocity, to accuratly pass it to the audio system - but there are other uses too, like motion blur, which also requires the actual velocity. I'm aware of a few hacks to achieve this (such as to increase the update frequency and just read out the raw velocity), but a clean solution is required. I basically want to implement something that more closely resembles http://www.gaffer.org/game-physics/fix-your-timestep

[spitfire2005]

there was a discussion about it here:
http://www.gamedev.net/community/forums ... _id=509254

[Lf3THn4D]

I second this! The current forward interpolation technique doesn't work at all for me. Instead of smoothing things out, i'm getting horrible jerking all the time. This is due to my vehicle simulation that has many forces applied every time step. It would be great if we can have a real slerp/lerp based interpolation technique.

[sparkprime]

Yeah, I disabled bullet's interpolation locally. My FPS is inconsistent enough that jerks from the motion of objects end up masked, also objects don't move fast enough (or close enough to the camera) to notice any jerking from lack of extrapolation in my setup.

Some time ago I tried to convince Erwin that what Bullet does is not interpolation but he didn't believe me