pixartist wrote:The center of gravity variable in the motion state OBVIOUSLY does not contain information about the location of the center of gravity of the object in world coordinates.
The motion state doesn't contain anything other than a transform. The transform however, is defined as the world coordinates of the center of gravity. Here's the motion state code that shows there is no secondary center of gravity necessary in a motion state:
Code: Select all
#include "btTransform.h"
///The btMotionState interface class allows the dynamics world to synchronize and interpolate the updated world transforms with graphics
///For optimizations, potentially only moving objects get synchronized (using setWorldPosition/setWorldOrientation)
class btMotionState
{
public:
virtual ~btMotionState()
{
}
virtual void getWorldTransform(btTransform& worldTrans ) const =0;
//Bullet only calls the update of worldtransform for active objects
virtual void setWorldTransform(const btTransform& worldTrans)=0;
};
#endif //BT_MOTIONSTATE_H
pixartist wrote:What it [The motion state] should contain, is the location of the center of gravity in the local space of the collision mesh, thus making it possible to change the center of mass.
btDefaultMotionState allows you to have a graphics world to physics world offset, but the value you feed into it is the "center of mass transform", i.e. the mass center of your collision shape. At no point do you change the actual center of mass in respect to the collision shape. As I stated before, changing the location of the center of gravity will cause serious issues unless you're careful and recompute the inertia and velocity vectors (you need conservation of momentum and angular momentum after all).
pixartist wrote:Why else would there be a constructor with matrix containing the start-tranformation and a variable centerOfGravity.
There is no centerOfGravity in either btMotionState or btDefaultMotionState, rather you have a "
m_centerOfMassOffset" which lets you define graphics world and physics worlds as different world axis (i.e. your physics says [1,0,0,0][0,1,0,0][0,0,1,0][0,0,0,1] but in the graphics world you rotate about an angle and shift by 2 and the function will return [1,0,0,2][0,0,1,0][0,-1,0,0][0,0,0,1] without needing to do the calculations yourself!). Both constructor arguments are optional, and are there to allow you to pre-load the transform start data in case you want to allow the system to revert to an old value (and set up your offset if needed)