Real-Time Physics Simulation Forum

Try turning on the CCD (Continuous Collision Detection) feature for your moving objects. It should prevent them from tunneling through collision geometry.

I think it is a scale problem. Your gravity is set to -10 which is about right for a world where 1 unit = 1 meter.
However your boxes are 10 x 10 x 10 which in meters is the size of a 3 story building!

I read through the PR (I hadn't realized it existed until you posted! D:) and it looks like it contains a bunch of QoL improvements. Thanks. However, a singular thought occurs to me since you opted to create a Multi-threaded (Mt) world class. What about soft bodies? The Mt dynamics world doesn't su...

This change https://github.com/bulletphysics/bullet3/pull/1144 which has now been merged, makes it substantially easier to integrate multithreaded Bullet 2.x into a project. It is no longer necessary to subclass any Bullet classes at all. Just do these things: - Use btCollisionDispatcherMt and btDis...

By the way, if you were getting a crash in the example browser when turning on multi-threading, it should be fixed in the latest.

I have recently gotten around to finally try updating Bullet to the latest trunk version and I was looking forward to the multi-threading available as outlined in this thread. However since looking over the instructions (a few posts up) and assessing the work that would need to be done on my part t...

No it isn't that simple. Bullet 2.x is single-threaded by default and does not have it's own threading system (task manager/job manager). However, you can use Cmake to configure the Bullet 2.x core libraries (LinearMath, BulletCollision, BulletDynamics) to have certain operations be threadsafe. In ...

Without going into deep details and through topic what are the minimum steps required to set-up basic physics multi-threading ? Is it just replacing btDiscreteDynamicsWorld with btDiscreteDynamicsWorldMt ? No it isn't that simple. Bullet 2.x is single-threaded by default and does not have it's own ...

Really glad to see the merge, thank you! One thing that I'd like to mention for anyone trying to integrate multithreaded bullet into their own project: There's a "gotcha" that happens if the pool allocator is called from a translation unit (.cpp file) outside of Bullet (like in the collisi...

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 c...

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.

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 goin...

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 ...

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 bo...

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 dyna...