maintaining determinism/reproducability after serialization / restarting at a given frame

[GoogleCodeExporter]

Bullet 2.x caches some information, such as broadphase pairs, contact points, 
local time and applied impulses. When restarting the simulation at some frame, 
or after serialization, this info is lost. This means the simulation will have 
different results (determinism).

See also 

http://bulletphysics.org/Bullet/phpBB3/viewtopic.php?f=12&t=6231
http://code.google.com/p/bullet/issues/detail?id=188
http://code.google.com/p/bullet/issues/detail?id=350
http://code.google.com/p/bullet/issues/detail?id=483

Original issue reported on code.google.com by erwin.coumans on 9 Jun 2011 at 7:15

[GoogleCodeExporter]

and http://code.google.com/p/bullet/issues/detail?id=476
(I accidently marked this as WontFix, but it should be eventually fixed of 
course)

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

[GoogleCodeExporter]

Issue 476 has been merged into this issue.

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

[GoogleCodeExporter]

Issue 188 has been merged into this issue.

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

[GoogleCodeExporter]

Issue 350 has been merged into this issue.

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

[GoogleCodeExporter]

Hey Erwin,

I actually spent quite some time on this , but we do still get some
undeterministic results, but it's kind of hard to know exactly why
as some scenes will be 100% deterministic and some none at all
for no apparent reasons.
One thing I noted though is that a scene that was very non-detereministic
with bullet compiled as double , was deterministic when compiled as float.
Might be a pure coincidence, just thought i'd mention it :)

Francois

Original comment by majestik...@gmail.com on 9 Jun 2011 at 7:48

[GoogleCodeExporter]

I haven't had time to look into this, but will do for Bullet 3.x

Note that the sleeping/deactivation time for each object needs to be reset 
properly. Are you doing that?

Original comment by erwin.coumans on 14 Jun 2011 at 6:34

[GoogleCodeExporter]

hmmm not sure will have to check it out
I've implemented quite a lot of things to try and get it deterministic
but always ended up having some scenes being not deterministic..

Francois

Original comment by majestik...@gmail.com on 14 Jun 2011 at 6:44

[GoogleCodeExporter]

Actually, looking at the code , we are setting the deactivationtime
back to 0 on reset.
I have a very simple scene to test and something i didn't mention before
that might help, in that scene, if i play over and over again, bullet 
produces a few different simulations and repeats them kind of randomly.
so it's not completly random results but a series of slight different
starting states i guess ....

Francois

Original comment by majestik...@gmail.com on 14 Jun 2011 at 7:04

[GoogleCodeExporter]

For Bullet 2.x, the only way to maintain determinism is to destroy and recreate 
everything from scratch. This works and is tested in the latest version of the 
Dynamica Maya plugin.

Original comment by erwin.coumans on 1 Mar 2012 at 5:52

[GoogleCodeExporter]

We actually managed to get pretty much everything
deterministic now, the only problem we're facing is the same
as what you mentioned in the dynamica patch note, we have some
bad ordering of the rbds because of the maya evaulation of some node.

There was a patch sometime ago about a not-order determinism but 
that wasn't enough to make it work.

Is Bullet 3.x based on the same assumption that objects are added
in the same order ? this would definitely be a very desirable feature
if it wasn't :)

Original comment by majestik...@gmail.com on 1 Mar 2012 at 8:07

[GoogleCodeExporter]

The ordering of Bullet objects in Maya should be consistent in Dynamica, 
because all objects are re-created and re-inserted in the same order by the 
solver node at restart.

Are you using your own Maya plugin?

I'm still working on Bullet 3.x but try to avoid the order issues.

Original comment by erwin.coumans on 1 Mar 2012 at 8:32

[GoogleCodeExporter]

yep working on wmRigid here :)

The ordering problem we have is more a design problem than anything else
because we try and not recreate the shapes etc as much as we can to keep
the speed up, and this optimization creates some objects to not be recreated
while some others are, etc.
So not at all a bullet problem, but would be nice if we could avoid working
around it.

Any estimate on the release of Bullet 3.x or when we can have an idea of 
how different the API will be ?

Original comment by majestik...@gmail.com on 2 Mar 2012 at 1:16

[GoogleCodeExporter]

See https://github.com/bulletphysics/bullet3/issues/127

Original comment by erwin.coumans on 30 Mar 2014 at 7:35

• Changed state: Moved