Drifting of dynamic object when kinematic object is nearby

[jorjee]

Hi,
My scene has a few "dynamic" cubes stacked on top of each other on a "static" ground with gravity acting. Now I have a "kinematic" object that moves close to the dynamic cubes. The cubes "wake up" when the kinematic object comes nearby. But furthermore, the cubes which are on top of other cubes (i.e. except the ones on the ground), also start slowly drifting in the horizontal plane. Remember that no contact was made. If one waits long enough, they drift and eventually fall of the cube on top of which they were resting. Is this a bullet bug ? (I'm using much of the structure of CcdPhysicsDemo - as in the Bullet SDK - and am using the Sequential Impulse Constraint Solver, FYI). Any help will be much appreciated!
Thanks,
Jorjee

[ShortyTwoMeters]

I can confirm that this is a bug that has cropped up between 2.73 and 2.74. I've been running my simulation with deactivation disabled and at some point I noticed that spheres with no initial velocity would begin rolling on the ground. Until now I didn't know what caused this but after reading your post I tried going back to 2.73 and the problem disappeared.

[Erwin Coumans]

Island activation currently happens when objects have AABB bounding box overlap, this usually happens before contacts are created.

Can you disable sleeping, and try to see if objects are creeping?

I can confirm that this is a bug that has cropped up between 2.73 and 2.74. I've been running my simulation with deactivation disabled and at some point I noticed that spheres with no initial velocity would begin rolling on the ground.

This is a likely a separate issue, related to btStaticPlaneShape that will be fixed for next release.
Are you using a btStaticPlaneShape?

If so, please set the default number of perturbation iterations and threshold to zero (instead of 3), around line 63 in bullet-2.74\src\BulletCollision\CollisionDispatch\btConvexPlaneCollisionAlgorithm.h

Code: Select all

		: m_numPerturbationIterations(0),
			m_minimumPointsPerturbationThreshold(0)

Hope this helps,
Erwin

[jorjee]

Hi Erwin,

Thanks a lot for your reply.

As you suggested, I disabled deactivation (assuming that's what you meant by "disable sleeping") of my dynamic objects too (was already doing that for my kinematic object). But, the dynamic objects still creep. In fact, now they creep right from the onset, as if they are always active (just as the DISABLE_DEACTIVATION state is intended to be perhaps?).

In general, it seems that the only situation when the objects do not creep is when their activation state is ISLAND_SLEEPING. Apparently because their velocities are enforced to zero in that case (around line 502 in btDiscreteDynamicsWorld.cpp). In all other activation states, there always seem to be a very small residual velocity of the order of 1e-05 or less that makes the objects creep. Should there be a velocity enforcement to zero for all non-ACTIVE_TAG states ?

I can confirm that this is a bug that has cropped up between 2.73 and 2.74.

This does seem like a separate issue. For confirmation, I tried Bullet 2.73, but objects are still creeping.

[ShortyTwoMeters]

Ah, I should have been more specific, it was with the static plane shape. Thanks for the fix, Erwin, it worked very nicely. It's a shame that these issues weren't related, with such an easy solution.

[jorjee]

I've since been able to boil this issue down further. This really has nothing to do with kinematic objects.

The issue really is:
Why does a dynamic object, which is on top of another dynamic object, and which is not sleeping (in either ACTIVE_TAG or WANTS_DEACTIVATION state), creep horizontally even when no horizontal forces are acting on it ?

This phenomenon can be seen in CcdPhysicsDemo.
If you notice the single column of cylinders to the left of the scene, at the very start of the simulation when they are still in active state, these cylinders can be seen to be creeping horizontally (as if slipping on the surface of the cylinder below), before they go to sleep and turn green.

[jorjee]

Hi Erwin,

Hope you'll give some input here.

The creeping problem seems to be originating at two places.

Fixed(?):
The m_worldTransform.m_basis of collision objects was often having very small values in its components when they should have been zero, possibly residues from the previous collision response. These residual values were finding their way into the impulse's linear component in the constraint solver (through the contact normal of collision manifold point).
The following code added to btTransform::getBasis() fixed this problem.

Code: Select all

		for(int i=0; i<3; i++)
		{
			btVector3 &basisVec = m_basis[i];
			if(fabs(basisVec[0]) == 1.f) { basisVec[1] = 0.f; basisVec[2] = 0.f; }
			else if(fabs(basisVec[1]) == 1.f) { basisVec[0] = 0.f; basisVec[2] = 0.f; }
			else if(fabs(basisVec[2]) == 1.f) { basisVec[0] = 0.f; basisVec[1] = 0.f; }
		}

Unfixed:
When friction constraints are solved, the friction impulse that is applied turns out to have a small horizontal linear component even when the body does not have any horizontal linear velocity (see btSequentialImpulseConstraintSolver::resolveSingleConstraintRowGeneric). This causes the body to have a small horizontal creeping velocity. Is this a limitation of the solver itself?

Thanks!
Jorjee