Closed GoogleCodeExporter closed 9 years ago
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
Issue 476 has been merged into this issue.
Original comment by erwin.coumans
on 9 Jun 2011 at 7:30
Issue 188 has been merged into this issue.
Original comment by erwin.coumans
on 9 Jun 2011 at 7:31
Issue 350 has been merged into this issue.
Original comment by erwin.coumans
on 9 Jun 2011 at 7:32
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
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
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
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
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
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
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
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
See https://github.com/bulletphysics/bullet3/issues/127
Original comment by erwin.coumans
on 30 Mar 2014 at 7:35
Original issue reported on code.google.com by
erwin.coumans
on 9 Jun 2011 at 7:15