Real-Time Physics Simulation Forum

btDiscreteDynamicsWorld::synchronizeMotionStates() is responsible to synchronize the transforms of rigid bodies in the discrete dynamic world with the application. However there is no synchronizeMotionStates() implemented for btMultiBodyDynamicsWorld(). Is there an alternative way to synchronize the transforms of btMultiBodyLink with the application ?

kingchurch wrote:btDiscreteDynamicsWorld::synchronizeMotionStates() is responsible to synchronize the transforms of rigid bodies in the discrete dynamic world with the application. However there is no synchronizeMotionStates() implemented for btMultiBodyDynamicsWorld(). Is there an alternative way to synchronize the transforms of btMultiBodyLink with the application ?

Multibody (featherstone) doesn't use the same sub-step iteration method that PGS dynamics world does, so the motion states are supposed to be in sync from the get-go. Your code should work as-is. Bullet worlds weren't made for simulation decoupled from display as-is, so if that's where you are getting errors/artifacts you might have to make some tweaks (a simple one is to just copy the world at each step, though that might be a drain on resources)

Basroil wrote:

kingchurch wrote:btDiscreteDynamicsWorld::synchronizeMotionStates() is responsible to synchronize the transforms of rigid bodies in the discrete dynamic world with the application. However there is no synchronizeMotionStates() implemented for btMultiBodyDynamicsWorld(). Is there an alternative way to synchronize the transforms of btMultiBodyLink with the application ?

Multibody (featherstone) doesn't use the same sub-step iteration method that PGS dynamics world does, so the motion states are supposed to be in sync from the get-go. Your code should work as-is. Bullet worlds weren't made for simulation decoupled from display as-is, so if that's where you are getting errors/artifacts you might have to make some tweaks (a simple one is to just copy the world at each step, though that might be a drain on resources)

Apparently the btMultibodyDynamicsWorld doesn't implement its own StepSimulation() and relies on the btDiscreteDynamicsWorld::StepSimulation() to do the sub-stepping and fixed/variable step etc. So I don't see how sub-step iteration method differs for the two solvers. However it's not hard to just read out the position/velocity of bodies/links after each step and send them to rendering even without the MotionState callback support. It seems the only advantage of using MotionState and synchronizeMotionStates() is for the interpolation support built in them. The current interpolation in rigid body motion state is linear extrapolation of world position based on world velocity. Such simple scheme won't work for Featherstone solver whose results need to be interpolated in reduced coordinates. I guess that complexity is one of the reasons it's not implemented yet. The only concern I have to mix interpolated rigid body PV (positions, velocity) and non-interpolated multiBody PV is possible visual artifact due to the interpolation. Probably better not use MotionState/Interpolation at all in case of mixed solver.

kingchurch wrote:Apparently the btMultibodyDynamicsWorld doesn't implement its own StepSimulation() and relies on the btDiscreteDynamicsWorld::StepSimulation() to do the sub-stepping and fixed/variable step etc. So I don't see how sub-step iteration method differs for the two solvers. However it's not hard to just read out the position/velocity of bodies/links after each step and send them to rendering even without the MotionState callback support. It seems the only advantage of using MotionState and synchronizeMotionStates() is for the interpolation support built in them. The current interpolation in rigid body motion state is linear extrapolation of world position based on world velocity. Such simple scheme won't work for Featherstone solver whose results need to be interpolated in reduced coordinates. I guess that complexity is one of the reasons it's not implemented yet. The only concern I have to mix interpolated rigid body PV (positions, velocity) and non-interpolated multiBody PV is possible visual artifact due to the interpolation. Probably better not use MotionState/Interpolation at all in case of mixed solver.

Yes, I did need to state it a bit better. Basically with the standard world you "guess" transforms for the remaining time (and "guesses" are synchronized after solving), but with multibody you just update the velocities directly during solving. However, it shouldn't affect the ability to display regardless, since you can still access the transforms when the solving is done.

On a secondary note I will probably avoid using synchronizeMotionStates since it's invoked every sub-step. Depending on if the rendering update is synchronous to the physics step and the frequency, a per sub-step motion state sync could be a waste of cpu cycles.