Real-Time Physics Simulation Forum

(1) Your Bullet libraries (LinearMath, specifically) must be compiled with: -DBT_ENABLE_PROFILE This may mean you need to compile the libs from source and add that option. (2) You wouldn't want to dumpAll() every step because that would make your simulation much slower than it already is, and would...

If you actually follow through with the CProfileManager stuff then you would get an idea as to where the bottlenecks are and how much time is spent in the various steps of the simulation. This would help you solve your problem, and also help you determine if you are actually fixing it with any worka...

Here are some ideas that occur to me: Assuming your tube is closed and a small ball will not fall out once it is placed inside... (1) Place a ball randomly (with some quantization) and let it fall. If it falls out the bottom of your simulation after a certain amount of time then conclude it was not ...

In this other thread you mention your Bullet simulation slows or blocks when you "increase the number of small balls". What you failed to mention in that thread, but what appears to be the case in this one, you are running those small balls inside a concave mesh object. If that really is your world ...

You have #include the right header file to obtain the CProfileManager declarations.

How many small balls are you talking about? What are the parameters of the hardware you're using? You might be running into the limits of Bullet on your system. There is a way to obtain detailed stats about where time is being spent inside the stepSimulation() context, which would help you identify ...

Don't set the margin of the convex hull to 0.0. Leave it at the default (which is 0.04m I think) and see if that makes your problem go away. My hypothesis is: you are allowing the box to actually penetrate the convex hull and the penetration resolution logic is kicking in. The penetration resolution...

The solution gets the current transform (position + rotation), overwrites the rotation part, and slams the body's transform to be that of the modified value. The end result is: the body's position doesn't change, but its rotation does. You set the angular velocity to be zero because... it shouldn't ...

The simplest way would be to use a btConvexHullShape for each cuboid wall and assemble them into a btCompoundShape . The points for each convex hull would be the eight corners of the wall box, and you could let all the points be in the local-frame of the btCompoundShape , so you could supply identit...

A solution to this problem I have used successfully is to not allow non-zero angular velocity of the character and just slam its rotation. In other words, in CharacterController::updateAction() do something like this: btTransform transform = body->getWorldTransform(); transform.setRotation(desiredRo...

When you change the rotation of the hollow box you are effectively "teleporting" it to a new transform. If its new transform happens to put its walls into penetration with balls that used to be inside --> then Bullet's "penetration resolution" algorithm will kick in and it doesn't care about keeping...

The simple way to do it is to use: btCollisionObject::setWorldTransform()

So the code might look like this:

When I look at btCollisionWorld::rayTestSingleInternal() I see: for many shapes it goes into triangleMesh->performRaycast() rather than concaveShape->processAllTriangles(). Maybe set your breakpoint there?

I see. You have a logic error rather than a question about Euler angles and quaternions. The good news is: I don't see the fault of the code you posted. The bad news would be: your bug is somewhere else. Maybe post your full code up on github? Good luck.