A callback function for bodies which should be synchronised?

Post Reply
User avatar
dotsquid
Posts: 22
Joined: Fri Jan 14, 2011 7:10 pm
Location: Ukraine
Contact:

A callback function for bodies which should be synchronised?

Post by dotsquid »

[SOLVED] I am using a custom MotionState. My class is inherited from the btDefaultMotionState class. It behaves similarly to btDefaultMotionState class, unless the setWorldTransform() method is pushing a pointer to the body into the list which is later used for syncing graphical entity with the physical body.
I noticed that after some simulation steps (approximately 1 to 50 "fine" steps) all active bodies are pushed to the list twice. Is it a normal behaviour of Bullet and I should filter double entries?
[/SOLVED]
Or maybe someone can suggest a callback function which I can use to generate a list of the bodies which have changed their transformations during the last simulation step?
Thanks in advance.
Last edited by dotsquid on Wed Sep 28, 2011 9:15 am, edited 1 time in total.
mi076
Posts: 144
Joined: Fri Aug 01, 2008 6:36 am
Location: Bonn, Germany

Re: btMotionState::setWorldTransform is called twice sometim

Post by mi076 »

used for syncing graphical entity with the physical body
Bullet's motion it is already interpolation, the goal is frame rate independence and it works for me so far. synchronizeMotionStates() is called every time stepSimulation was called, independent of physics step wa done or not, or it can be called several times per single step, if there are substeps.
Here is stepSimulation function, look at synchronizeMotionStates() etc..
http://www.bulletphysics.com/Bullet/Bul ... tml#l00227
User avatar
dotsquid
Posts: 22
Joined: Fri Jan 14, 2011 7:10 pm
Location: Ukraine
Contact:

Re: btMotionState::setWorldTransform is called twice sometim

Post by dotsquid »

mi076
Thanks. I have forgotten about the substeps. Now it's clear why I have double entries. And of course I could receive even more entries of the same body if the number of substeps was greater than 2.

Any suggestions concerning this?
dotsquid wrote:Or maybe someone can suggest a callback function which I can use to generate a list of the bodies which have changed their transformations during the last simulation step?
User avatar
dotsquid
Posts: 22
Joined: Fri Jan 14, 2011 7:10 pm
Location: Ukraine
Contact:

Re: btMotionState::setWorldTransform is called twice sometim

Post by dotsquid »

Bump
User avatar
dotsquid
Posts: 22
Joined: Fri Jan 14, 2011 7:10 pm
Location: Ukraine
Contact:

Re: A callback function for bodies which should be synchroni

Post by dotsquid »

Some sort of BUMP
To clarify what am I doing and why.

I've got a list of the physical bodies which were transformed during the last simulation step and therefore the graphical entities should be synced with those bodies.
That list is cleared before each simulation step and then filled. The filling is done through the setWorldTransform method of the pxMotionState class which is derived from btDefaultMotionState. That method does nothing except invoking btDefaultMotionState::setWorldTransform and pushing the pointer to the body into that list.

I faced the problem of double (and even more) entries of the same body in the list. mi076 has given me the cue that this is caused because of several substeps of the simulation.
I solved the problem by using only a part of the list during syncing, simply using list.size() / _numSimulationSubSteps, instead of list.size(), as far as I assumed that every substep simulates the same bodies.

But it appears that if the bodies are numerous and the simulation takes much time, substeps may simulate different bodies. This causes the desynchronization of physical bodies and graphical entities because some bodies are in the unused part of the list.

So, the questions are:
1) If the simulation takes much time, why the number of substeps may be still greater than 1?
2) Is my assumption about that the substeps may simulate different bodies right?
3) Is there any other way to sync graphical entities and physical bodies?
Post Reply