btDbvtBroadphase nondeterministic?

[marshall]

We've been using btAxisSweep for some time and we've had great results that were always consistent when rerunning sims. Recently we switched to using btDbvtBroadphase and I notice that the results are always different from sim to sim.

Before digging deep into the code I'm curious if anyone else has noticed this? If not, is there something about initialization that I'm not doing? Basically I'm just allocating a btDbvtBroadphase object in place of my previous btAxisSweep3/bt32BitAxisSweep3 object.

[Erwin Coumans]

We recently solved this issue: http://code.google.com/p/bullet/issues/ ... &start=100

Can you try to use the latest Bullet SVN trunk, and see if it solves your issue?

You can find all steps for deterministic/reproducable results in Bullet/Demos/OpenGL/DemoApplication/DemoApplication.cpp, method

Code: Select all

void	DemoApplication::clientResetScene()

Please make sure to call the new broadphase 'resetPool(btDispatcher* dispatcher);' method, constraint solver reset, and remove and re-add all objects to the world.

Hope this helps,
Erwin

[marshall]

Thanks for the reply Erwin. There is a comment in the log:

Did some investigation into why btDbvtBroadphase is not deterministic. When using
btSortedOverlappingBroadphase, it is deterministic now, with those fixes.

In svn the btDbvtBroadphase is using a btHashedOverlappingPairCache by default. Should
I be passing in a btSortedOverlappingPairCache at allocation instead?

[Optic]

I just got this exact same problem... If i don't use ray tracing in btAxisSweep3, it stays deterministic...

I have also included a call to m_raycastAccelerator->resetPool(dispatcher) in resetPool() but didn't fix it...

What should I be doing? Using a btSortedOverlappingPairCache instead of the default hashed version? I looked at the demon and none seem to be using btSortedOverlappingPairCache so I was wondering how you were testing for determinism...

Cheers...

[Optic]

sorry its my stuff that is not deterministic...