Gravity and deactivation

[Jyavoc]

So, I'm encountering something which (to me) seems confusing and undesirable. When I have a kinetic rigid body in a world with gravity, gravity will only affect the rigid body and pull it down while the rigid body's activation state is active. Furthermore, after activating the activation state, even though the rigid body is being moved through gravity, the rigid body will deactivate; therefore, my only solution thus far to make sure that rigid bodies are always affected by gravity, I've been forced to use DISABLE_DEACTIVATION as an activation state. But this doesn't seem desirable at all, because there would be no gain from using activation states if we're merely suppose to disable it entirely.

Is there a way to allow a rigid body to be affected by gravity without being active? Or to allow the rigid body to at least not deactivate until the effects of gravity are counteracted by a ground (the gravity stops moving the rigid body)?

[Jyavoc]

I think I figured out my problem; I have too low of a linear threshold, and so while my btRigidBody is moving, it is actually "non-moving." Because I found so little documentation on activation states and the like, I'm posting the "wealth" of my knowledge of the subject here, so that hopefully someone else can learn (or, if I'm mistaken in my understanding, that someone can correct me).

------------

btCollisionObjects have what is known as an activation state. This state is an optimization in regards to how Bullet manages the world; if whatever physics world model you're using has 10,000 collision objects, then each time you step the simulation, you would need to perform collision checks an inordinate number of times (something like 99,990,000 collision tests). Even if those checks were lightning fast, that's still almost 100,000,000 checks each frame of your application (if you step the simulation at each frame, as is commonly done).

So Bullet made a logical conclusion — only test for collisions involving a pair of objects where at least one object has moved since we last checked. For instance, we have 10,000 objects, but let's say that only one object has actually moved, and other other 9,999 objects remained stationary. If these 9,999 objects that didn't move weren't colliding before, and they haven't moved since the last time we checked, how would they be colliding now (unless we as programmers made them to, but that's another issue). So instead of checking 99,990,000 collision pairs (10,000 objects * 9,999 potential other objects to collide with), Bullet only has to check 9,999 collision pairs (the one object that moved * 9,999 other objects that this object could have collided with).

Bullet is designed so that we manually tell it when an object is about to move. In order for Bullet to do any concerning a btCollisionObject, that btCollisionObject must be in an active activation state. If it is active, then velocity will be applied, collision will be checked, and so on. If the btCollisionObject is in a deactivated activation state, then it will be considered stationary; velocity won't be applied, collision will be skipped for this object (not that other objects can't collide with this object; just that this object can't collide with other objects).

However objects that are active but haven't moved will be deactivated; if everything remained in its active state forever, there would be very little gain from having activation states at all (it would only exclude objects which have never moved before). This process happens automatically, after a period of time known as the deactivation time has elapsed. But this deactivation time might not suit your individual needs; therefore, there's one of two ways to work with it:

• btCollisionObject::setActivationState(DISABLE_DEACTIVATION); This forces the collision object to never deactivate. This function will activate the collision object, and until you otherwise specify, the collision object will remain active.
• btCollisionObject::setDeactivationTime(btScalar); Providing a btScalar to this function will set the new deactivation time for this collision object.

But how do we classify what constitutes "not having moved?" For btRigidBody objects, there are two convenient concepts added: linear threshold and angular threshold. Both a btRigidBody's linear velocity and angular velocity are btVector3s, whereas these thresholds are btScalars. Therefore, it is my understanding that these scalar thresholds are either:

1. Thresholds to compare magnitude of the velocity against
2. Thresholds that, should all three components of the velocity (X, Y, and Z) fall beneath, the velocity will be considered (0, 0, 0)

Regardless, the linear threshold of a btRigidBody is this threshold for the linear velocity, and angular threshold is the threshold for the angular velocity. As long as the linear velocity of an active btRigidBody is above the linear threshold, the btRigidBody will be considered "moving;" but when the linear velocity drops beneath this threshold, the btRigidBody will be "non-moving," and the deactivation time will begin to count down for that btRigidBody. The same scenario would apply for angular velocity. It would be worth noting that, as activation state applies to both linear movement and angular "movement," both linear and angular velocity would need to be "non-moving" in order for that btRigidBody to be "non-moving." These two thresholds can be changed using the sole mutator method for btRigidBody: btRigidBody::setSleepingThresholds(linear, angular), where both linear and angular are btScalar thresholds of whatever value. Note that, because there is only this one method, you have to set both at the same time. If you only want to set one, you can always use code such as this:

Code: Select all

btRigidBody rigidBody;
rigidBody.setSleepingThreasholds(10.0, rigidBody.getAngularSleepingThreshold());

-----------------
Hopefully someone will find this helpful, and will have less of a scavenger hunt to figure out the ins and outs of beginning to work with activation states.

[Jyavoc]

Regarding how the thresholds are used when determining of a velocity constitutes "moving" or "non-moving," I tracked it down in the source, and it's the first of the two possibilities that I suggested. In terms of linear threshold, a btRigidBody is considered "non-moving" if the square of the linear threshold is greater than (but not equal to) the square of the length of the linear velocity. In the code, it is:

Code: Select all

if ((getLinearVelocity().length2() < m_linearSleepingThreshold*m_linearSleepingThreshold) &&
			(getAngularVelocity().length2() < m_angularSleepingThreshold*m_angularSleepingThreshold))
		{
			// "non-moving"
		} else
		{
			// "moving"
		}