Bullet dynamics always assumes the collision shape origin is the center of mass (COM). However, 3D model origins rarely coincide with the COM. A simple conversion of OSG geometric data into a collision shape would almost certainly result in incorrect dynamics due to this issue.
osgBullet supports 3D models with non-origin COM. The support is implemented in the MotionState class and the collision shape creation utilities. If your application uses the rigid body creation utilities, then you merely specify the COM in the CreationRecord.
// Begin_doxygen example code block osg::ref_ptr< osgbDynamics::CreationRecord > cr = new osgbDynamics::CreationRecord; if( setCom ) cr->setCenterOfMass( com ); cr->_sceneGraph = mt; cr->_shapeType = BOX_SHAPE_PROXYTYPE; cr->_parentTransform = m; cr->_restitution = 1.f; btRigidBody* rb = osgbDynamics::createRigidBody( cr.get() );
Note that the call to setCenterOfMass() is conditional; if you don't call it, osgBullet will use the bounding volume center as the COM. However, osgBullet never uses the origin as the COM, unless you specify it directly with a call to setCenterOfMass(), or it just happens to coincide with the model origin.
If your application doesn't use the rigid body creation utilities, then you should emulate the RigidBody.cpp source code.
The centerofmass example demonstrates setting COM on a 3D model. It uses the com.osg model file, which has its origin at the lower-left front corner. To see the model origin, use the osgWorks utility osgwbvv:
osgwbvv com.osg --box --origin
Clearly, using the model origin as the COM would be incorrect. You can see this incorrect behavior when you run the example; look at the model on the left. If osgBullet (or your application) were to do a naive comversion of OSG geometric data to a Bullet collision shape, this is what you'd get.
If you don't specify a COM at all (that is, your application doesn't call osgbDynamics::CreationRecord::setCenterOfMass() ), osgBullet uses the subgraph bounding volume center as the center of mass. This works well for many models, but not for com.osg. To see this incorrect behavior, run the example and look at the model on the right.
The object in the center of the example has a correct COM, which produces correct rigid body dynamics. This was accomplished using the code above.
1.7.2