Has anyone any experiences/code to share in hacking Bullet to do multithreaded collision detection? I remember reading somewhere that at least one group of people had hacked their own dispatcher together.
(The SPU code gives quite different results to the normal dispatcher particularly when dealing with compounds - GJK seems to be used over box-box, for example.)
Currently naively hacking at btOverlappingPairCache.cpp to make it run the callbacks via a pool of pthreads, but quickly finding that this is not a straightforward exercise not least due to the thread unsafeness of Bullet's memory allocator functions.
Anyone have any tips? We're using 2.79 as a base for our engine. I hear 3.x will have a new threading implementation, but we'd like to hack something simple together for 2.x if possible.
Thanks
Alex
Non-SPU multithreaded collision detection
-
- Posts: 52
- Joined: Wed Sep 28, 2011 8:36 am
- Location: France
Re: Non-SPU multithreaded collision detection
Got exactly the same needs, but not enough time to work on it for now...
Would be happy to hear about if you find something interesting
Would be happy to hear about if you find something interesting
-
- Site Admin
- Posts: 4221
- Joined: Sun Jun 26, 2005 6:43 pm
- Location: California, USA
Re: Non-SPU multithreaded collision detection
I'll get to that hopefully soon.
There is an older branch that refactors the BUllet collision detection so it is easier to make it multi-threaded.
See
http://code.google.com/p/bullet/source/ ... Allocation
There are two main issues that prevent multi-threaded regular collision algorithm execution:
1) contact manifold allocation. This can be relatively easily fixed in the contact allocation.
2) temporary modification of collision shapes, while processing collision algorithms (such as btCompoundShape). This is fixed by that StackAllocation branch.
Thanks,
Erwin
There is an older branch that refactors the BUllet collision detection so it is easier to make it multi-threaded.
See
http://code.google.com/p/bullet/source/ ... Allocation
There are two main issues that prevent multi-threaded regular collision algorithm execution:
1) contact manifold allocation. This can be relatively easily fixed in the contact allocation.
2) temporary modification of collision shapes, while processing collision algorithms (such as btCompoundShape). This is fixed by that StackAllocation branch.
Thanks,
Erwin
-
- Posts: 7
- Joined: Thu Mar 01, 2012 10:07 pm
Re: Non-SPU multithreaded collision detection
Thanks Erwin, good to hear I was on the right track! Am currently hacking the Compound collision algo but will check out this branch.
Cheers
Cheers
-
- Site Admin
- Posts: 4221
- Joined: Sun Jun 26, 2005 6:43 pm
- Location: California, USA
Re: Non-SPU multithreaded collision detection
I started working on this, in a work-in-progress branch here:
https://www.assembla.com/code/bullet3/subversion/nodes
assembla is basically the latest Bullet trunk from GoogleCode with a new contribution from Apple (SIMD for x86 and iOS) and passing a btCollisionObjectWrapper around instead of modifying the collision objects/shapes. Note that it is not fully finished yet, collision filtering and softbody versus concave is broken (and possibly other things).
Once the work in this repository is stable, I commit it to Bullet trunk in GoogleCode.
Thanks,
Erwin
https://www.assembla.com/code/bullet3/subversion/nodes
assembla is basically the latest Bullet trunk from GoogleCode with a new contribution from Apple (SIMD for x86 and iOS) and passing a btCollisionObjectWrapper around instead of modifying the collision objects/shapes. Note that it is not fully finished yet, collision filtering and softbody versus concave is broken (and possibly other things).
Once the work in this repository is stable, I commit it to Bullet trunk in GoogleCode.
Thanks,
Erwin