ball receiving force but not rolling..

[EliasNemer]

hello,

below is a video of a certain situation in my game.. as you can see the trajectory of the cueball is set to intercept the position of the second ball.

it hits the ball but the other ball moves but does not roll, as if it is clamped..

can someone please let me know how to fix this, and what may be the cause?

https://youtu.be/vQKV7pUHMYw

[drleviathan]

An idea occurred to me about this...

Are you sure the red ball was actually hit? Perhaps its visible location was not quite the same as its colliding position and the passing cueball "activated" its RigidBody and caused a final update of the rendered ball's world transform via a call to the MotionState::setWorldTransform() method.

I've encountered that problem before in a custom game engine using Bullet and it is possible BulletSharp and/or whatever is the Unity game engine wrapper around Bullet also suffers from it. Here is how it happens...

The BulletSharp implementation probably has a MotionState that bridges the RigidBody to its RenderObject. The Bullet API will call MotionState::setWorldTransform() every substep on an active RigidBody... when it has a MotionState. That is where the RenderObject learns about its new transform and the key here is: the body must be active.

Meanwhile, Bullet will deactivate the RigidBody when its velocities have been below some thresholds for longer than 2 seconds.

The problem is: the deactivation happens BEFORE the MotionStates are synchronized, but AFTER the RigidBodies have been integrated forward. Which means, if your ball was moving very slowly (non-zero velocity but below the thresholds) when it was deactivated then the final MotionState::setWorldTransform() is NOT called and its RenderObject is left a little bit behind where the actual RigidBody is located.

The final ingredient to the "bug" you're seeing is: when an active RigidBody's bounding box overlaps that of an inactive RigidBody then the second body is activated. This happens due to bounding box overlap and NOT because of an actual collision (the collision gets computed later). So your cueball passed very close to the red ball and activated it, but did not hit it, and the red ball's RenderObject received a fresh transform which finally allowed your game to draw it where it had actually stopped.

Now that I've stepped through the code and thought about this problem again I realize: this is a bug in Bullet and could be fixed without too much trouble. However in the meantime, if this really is your problem then you will probably have to find a workaround. One way to do it might be to lower the velocity thresholds of the deactivation check, which will reduce the maximum possible transform discrepancy, possibly low enough to be unnoticeable. For a Billiard simulation where all the dynamic objects are simple spheres this is a safe workaround, but might not work for a more complicated pile of objects like a big stack of boxes: they might rattle and shift forever and never get deactivated.

[drleviathan]

PR-2732 has a proposed fix for the "sometimes don't get final MotionState::setWorldTransform() on deactivation" bug.

https://github.com/bulletphysics/bullet3/pull/2732

[EliasNemer]

Very interesting.. Thank you for your comment, i will try the fix.

[EliasNemer]

so i tried what u said, a few observations,,

i decreased the velocity threshold angular and linear by a factor of 50, this decreased the error as u said, but the trajectory simulation started loosing accuracy.

i took off the dampening on the ball, and it worked..

thanks allot for your info..