Non-deterministic behaviour of btDiscreteDynamicsWorld due to member m_localTime

[GoogleCodeExporter]

What steps will reproduce the problem?
1. create a btDiscreteDynamicsWorld and add some bodies
2. perform several simulation steps and record position of bodies
3. reset the solver and the positions of all bodies
4. perform several simualtion steps and record position of bodies again

What is the expected output? What do you see instead?
The trajectory of the bodies in the first and second simulation run should
be identical, however, they are not. They are only identical when creating
a new btDiscreteDynamicsWorld object for the second simulation run.

What version of the product are you using? On what operating system?
Bullet from svn, Rev. 2040 on Ubuntu

Please provide any additional information below.
The problem is, that internally, the btDiscreteDynamicsWorld object has a
member m_localTime, which changes during the simulation but cannot be
reset. m_localTime is used to keep track of the remaining time fraction
till the time at which the next simulation step should be performed. (It is
different from zero only on creation or when the simulation time is not a
integer multitute of the internal time step.) When the m_localTime is not
reset, the second simulation run yields different results from the first.
At the moment it is not possible to set m_localTime from outside, since it
is private and there are no setters.

I see several possible solutions:
(1) provide a resetAll() method for the btDiscreteDynamicsWorld, which
resets the internal state of the world (which includes not only m_localTime
but also the dispatcher pool and the constraint solver as in the Bullet
demos.) This would make it very convenient to use the same
btDiscreteDynamicsWorld object for several simulation runs in an
deterministic manner.

(2) make m_localTime accessable through getters and setters so it can be
manually reset.

One thing I am still wondering about is why m_localTime is initalized with
1/60 in the constructor. This leads to an additional internal simulation
step on the first time the stepSimulation() method is called.

Original issue reported on code.google.com by eweitna...@gmail.com on 2 Mar 2010 at 9:34

• Merged into: #519

[GoogleCodeExporter]

We should expose m_localTime (or a reset) and probably set the m_localTime to 0.

I have to look into this.
Thanks for the feedback,
Erwin

Original comment by erwin.coumans on 3 Mar 2010 at 10:53

[GoogleCodeExporter]

As a workaround, it is possible to reset m_localTime by calling 
stepSimulation(0, 0, 0).

---JvdL---

Original comment by ja...@orcon.net.nz on 4 May 2010 at 6:26

[GoogleCodeExporter]

Original comment by erwin.coumans on 9 Jun 2011 at 7:32

• Changed state: Duplicate

[GoogleCodeExporter]

So did anything changed since that?

Original comment by paulshtu...@gmail.com on 5 Aug 2012 at 4:24