Real-Time Physics Simulation Forum

lunkhound wrote:Thanks for those fixes!

I haven't merged the determinism one yet because I want to see what the performance implications are. I'll have a look at it later.

You're welcome!

During my tests there was close to no difference in performance, but your mileage may vary.
As for the other fix, there are still two const_casts in there that aren't needed. I don't remember why I added those in the first place, but I'm sure I needed a non const reference for some reason during testing.

So did the kinematic get fixed?

Hello guys,

I see that you could get Bullet to run with multithreading I thought about this some time ago because the GPU pipeline is not ready yet. So what I would like to ask is if it is possible to merge the multithreading abilities that lunkhound added to his bullet version into the original bullet3 repository? I think that would be an interesting feature for Bullet3 as long as the GPU pipeline is not working yet.

benelot wrote:Hello guys,

I see that you could get Bullet to run with multithreading I thought about this some time ago because the GPU pipeline is not ready yet. So what I would like to ask is if it is possible to merge the multithreading abilities that lunkhound added to his bullet version into the original bullet3 repository? I think that would be an interesting feature for Bullet3 as long as the GPU pipeline is not working yet.

Too many unknowns on how it'll affect others using their own forks. For my own use, the full implementation will break my project (well, my primary one at least) into a million pieces. Just fork off of lunkhound's fork and you'll be fine

Granyte wrote:So did the kinematic get fixed?

The version with the fix for kinematic objects is here: https://github.com/lunkhound/bullet3/tree/kinematic-fix

I have kept that change in a separate branch because it likely causes trouble for the featherstone multi-body point-to-point constraint. The MultiBody dynamics world isn't threadable anyway, so it's no loss if you want to use threads.

I have just started using bullet. Is this thread related to the master's multithreaded examples?

I don't know if this project is active anymore, but I sometimes get crashes when using constraints that can be constrained against the world. In such cases, Bullet actually constrains the rigid body against what it calls a "fixed body" - see btTypedConstraint::getFixedBody(). The fixed body does not appear to get added to the world and so m_uniqueId is uninitialized.

kermado wrote:I don't know if this project is active anymore, but I sometimes get crashes when using constraints that can be constrained against the world. In such cases, Bullet actually constrains the rigid body against what it calls a "fixed body" - see btTypedConstraint::getFixedBody(). The fixed body does not appear to get added to the world and so m_uniqueId is uninitialized.

Thanks for reporting that. I've added a fix for that case.

https://github.com/lunkhound/bullet3/tree/kinematic-fix

I have updated my fork with a new branch based on the latest bullet code (2.85 as of this writing). This new branch is a complete refactor of the previous changes with the goal of minimizing changes to core bullet classes so that merging changes from upstream is easier. This new branch incorporates all of the fixes from the "kinematic-fix" branch.

https://github.com/lunkhound/bullet3/tree/thread-work4

A few additions in the latest:

• - Faster raycasts. The previous version introduced a dynamic allocation with every raycast (which is bad for performance) in order to make it threadsafe, that is now fixed so multithreaded raycasts should be the same performance as original bullet
  - The benchmarks app in the example browser can now be run multithreaded (press 'm' key to toggle between multithreaded dynamics world and normal). This includes:
  • - "benchmarks/3000 boxes"
    - "benchmarks/1000 stack"
    - "benchmarks/ragdolls"
    - "benchmarks/convex stack"
    - "benchmarks/prim vs mesh"
    - "benchmarks/convex vs mesh"
    - "benchmarks/raycast"
  - The raycast example (part of benchmark demo) has been modified to do raycasts in parallel

New classes added:

• - btSimulationIslandManagerMt-- new subclass of btSimulationIslandManager. The original simulation island manager class is untouched and all multithreading changes are now contained in this new class.
  
  - btDiscreteDynamicsWorldMt-- new subclass of btDiscreteDynamicsWorld containing multithreading changes. The original class has a few minor changes to internal functions but is functionally unchanged.

By encapsulating the changes in subclasses, it should be much easier to merge in upstream changes going forward.

Notes for converting from previous multithreading to thread-work4 branch:

• Replace references to btSimulationIslandManager with the "Mt" version
  Replace references to btDiscreteDynamicsWorld with the "Mt" version
  In your DynamicsWorld class, if you've overridden createPredictiveContacts(), add a call to releasePredictiveContacts() at the start of it

I think that's about it.

[edited to remove references to btSequentialImpulseConstraintSolverMt which was dropped from the latest]

Any chance of a pull request to the main repo with the refactored code? I see the old request on the Bullet repo as failing to build, but if this build compiles/works and the actual changes are smaller I don't understand maintaining your own repo for this.

Mako_energy02 wrote:Any chance of a pull request to the main repo with the refactored code? I see the old request on the Bullet repo as failing to build, but if this build compiles/works and the actual changes are smaller I don't understand maintaining your own repo for this.

Possibly. The old pull request is not going to be accepted, the only reason it is still open is to allow people to discover this fork, and the fact that it has some useful commentary. I'm not sure that the reasons Erwin had for not accepting the existing pull request have been addressed in this latest branch. In that case I don't want to clutter up his repo with multiple pull requests for the same thing. I think the best thing to do is to merge these latest changes into the branch of the existing PR. That should update the pull request.

please create a new fresh pull request, I consider a merge. Thanks for the work!

Erwin Coumans wrote:please create a new fresh pull request, I consider a merge. Thanks for the work!

OK, will do. I just need to do a bit more testing on it first.

OK, I created a new pull request:
https://github.com/bulletphysics/bullet3/pull/847

I used a virtual machine to test it on Ubuntu/Cmake/GCC. So that configuration should be working now.

I made some changes to the example browser so it's more user-friendly (for the multi-threading part).
Once it is compiled to be multithreaded, the demos which support multithreading have a button to switch into multithreading mode. You then have to restart that demo by double-clicking, at which point various other buttons and a slider widget will appear, allowing you to change between the various available threading APIs and the number of threads to use. Also there is a button to toggle the display of basic profiling info.

All of the actual multithreading stuff was moved into examples/CommonInterfaces/CommonRigidBodyBase.cpp so that it could be shared among the other demos.

Thanks for all the work and the community discussion related to this. I accepted and merged the latest version of lurkhound here:
https://github.com/bulletphysics/bullet3/pull/847

I reviewed the files and the single-threaded version seems to still work fine, need to do some more tests on the multithreaded parts,
and may re-organize the files in 'CommonInterfaces' later.

Also, it would be nice to support multithreading of a single island in the future, as used in the old (removed) BulletMultiThreading, and in Bullet3 OpenCL.
It uses graph coloring to split batches of constraints that can be solved in parallel. Then at each iterations, the results are merged.

Thanks!