## Moments of inertia

Dirk Gregorius
Posts: 875
Joined: Sun Jul 03, 2005 4:06 pm
Location: Kirkland, WA

### Moments of inertia

Is there any particular reason why Bullet uses box inertias to approximate cones, cylinders and capsules? Especially deriving btCylinderShape from btBoxShape is somewhat confusing since a box is very obviously not a cylinder. So what is the advantage of not using the proper inertia tensors?

Erwin Coumans
Posts: 4223
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA
Contact:

### Re: Moments of inertia

Dirk Gregorius wrote:Is there any particular reason why Bullet uses box inertias to approximate cones, cylinders and capsules? Especially deriving btCylinderShape from btBoxShape is somewhat confusing since a box is very obviously not a cylinder. So what is the advantage of not using the proper inertia tensors?
This was done on intentionally, to demonstrate that an approximated inertia tensor is accurate enough for most purposes. Several collision shapes use an approximate box-inertia tensor. I haven't found any reason why to use a better approximation, neither got any issue reports or received patches for it.

Can you create/modify a Bullet demo that shows that the Cylinder requires/benefits from a better moment of inertial calculation?
Thanks,
Erwin

Dirk Gregorius
Posts: 875
Joined: Sun Jul 03, 2005 4:06 pm
Location: Kirkland, WA

### Re: Moments of inertia

Well, I would argue that an approximation would make sense when the inertia would be difficult to compute, but the inertia tensors are incredible simple and there is no reason to not use the correct ones. Actually I don't see any reason to cheat here, especially since this is usually an offline computation. Basically just copy paste the three-liners form e.g. Mathworld. I agree though that you should hardly notice any differences for capsules and cylinders. Not sure for cones though...

Erwin Coumans
Posts: 4223
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA
Contact:

### Re: Moments of inertia

Dirk Gregorius wrote:I agree though that you should hardly notice any differences for capsules and cylinders.
It is not noticeable, that is the main point. I've seen a popular physics engine using spherical inertia tensors for boxes (with roughly equal lengh/width/height dimensions).

Important to note: Bullet allows adding collision margins to objects, also known as spherical inflation. So a box can be turned into a capsule: set the halfextents to (1,0,0) and set the margin to the radius of the capsule. It is not trivial to adept the inertia tensor calculation for such case. The same holds for cylinders: you can add some margin to make it a 'rounded cylinder'. A 'real' cylinder inertia tensor doesn't match a cylinder with margin. Those are just a few examples of approximations.

This is the deal: if you can create a reproducing testcase that shows the need for better inertial tensor approximation for cylinders, I will be happy to improve it.
Thanks,
Erwin

Dirk Gregorius
Posts: 875
Joined: Sun Jul 03, 2005 4:06 pm
Location: Kirkland, WA

### Re: Moments of inertia

I forgot about the margin. This is indeed true and in this case I agree that it makes sense to approximate for simplicity. Without this I don't see any reasons to use this approximation though. For the sphere inerita I would argue that this is a speed/memory optimization since you can store the inertia as a scalar and it is invariant under rotations (that means constant). As you know there exist better methods for this though.

Note that we already mess with the inertia a lot. E.g. we ignore the corioles term in the Newton-Euler equation and we also usually artificially scale the inertia tensor for improved ragdolls (in particular stiffer limits). This is as you know indeed noticeable, so I argue one should not mess with the inertia too much...

chand81
Posts: 6
Joined: Thu Aug 16, 2007 7:19 am

### Re: Moments of inertia

The inertia tensor for a cube is similar to that of a sphere - both scalars. So the approximation is justified.
But I find it hard to understand that rotating a cube about any axis would require the same amount of work irrespective of the choice of axis. (this is understandable for a sphere, whichever axis is chosen, effort required to rotate the sphere is the same.)

I agree with Dirk that the inertia tensor should be computed as accurately as possible as its an off line computation. I think computation of inertia tensor for chamfered boxes & cylinders should be possible as these could be broken down to standard primitives.

Chamfered cylinder can by represented by standard primitives - cylinder & torus.

Erwin Coumans
Posts: 4223
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA
Contact:

### Re: Moments of inertia

chand81 wrote: But I find it hard to understand that rotating a cube about any axis would require the same amount of work irrespective of the choice of axis
Generally the local inertia tensor is usually a 3x3 matrix, with an optional center of mass offset. Bullet btRigidBody requires the inertia tensor to be aligned with the center of the rigidbody. Also it requires the inertia frame of orientation to be aligned with the rigidbody local coordinate frame. This means the inertia becomes a vector3, instead of a 3x3 matrix. Requiring the frames to be aligned is not an approximation.

Each frame, the local inertia is transformed into worldspace, resulting in a 3x3 matrix. This means when the rigidbody moves and rotates in space, the moment of inertia in worldspace keeps aligned with the worldspace axis of the body. The inverse of this matrix is kept for calculations, for performance reasons. This is not an approximation either.

As I mentioned to Dirk already, if you can provide a reproducing case in a Bullet demo that shows any benefit from a better approximation, I'm happy to incorporate the improvement.
Hope this explains the situation,

chand81, thanks for those great looking pictures, what software did you use to generate those?
Thanks,
Erwin

chand81
Posts: 6
Joined: Thu Aug 16, 2007 7:19 am

### Re: Moments of inertia

Erwin Coumans wrote:This means the inertia becomes a vector3, instead of a 3x3 matrix. Requiring the frames to be aligned is not an approximation.

Each frame, the local inertia is transformed into worldspace, resulting in a 3x3 matrix. This means when the rigidbody moves and rotates in space, the moment of inertia in worldspace keeps aligned with the worldspace axis of the body. The inverse of this matrix is kept for calculations, for performance reasons. This is not an approximation either.
Mm , so my interpretation about effort required to rotate a cube is correct?

I can understand that the worldspace inertia will require a 3x3 matrix as the orientation matters: in the case of the sphere this would be a uniform scaling matrix premultiplied by a rotation matrix.

The local space inertia matrix would be a diagonal matrix (vector3) if the rigid body is symmetric about each x, y & z axis - as the symmetry would lead to zero product of inertia terms (off diagonal elements).

Please correct me if I've misinterpreted.

Thanks.
Erwin Coumans wrote:what software did you use to generate those?
3ds Max viewport captures and a bit of photoshop.

DevO
Posts: 95
Joined: Fri Mar 31, 2006 7:13 pm

### Re: Moments of inertia

Hi,

this approximation is may be suitable for simple convex shapes but how about not symmetric Compounds and Mesh shapes???

You can simple create Mesh with really strange behavior using simple Box inertia.

Dirk Gregorius
Posts: 875
Joined: Sun Jul 03, 2005 4:06 pm
Location: Kirkland, WA

### Re: Moments of inertia

Erwin,

I just looked at your code for the compound shapes and you just use the AABB as approximation for the inertia inertia. Computing inertias of compound bodies is a straight forward problem and well described (messy though that is why I looked at Bullet). So what is so bad about using correct inertias? I really don't see the reason for this (over) simplification. What are you actually doing for meshes?

Cheers,
-Dirk

melax
Posts: 42
Joined: Mon Apr 24, 2006 4:55 pm

### Re: Moments of inertia

If you just have a point cloud but dont have the faces/boundary of a convex mesh then it might be easier to fit a box and use that to compute inertia. After all, if the gjk collision code doesn't do hill climbing, then the faces aren't even needed.

The bullet module for btConvexTriangleMeshShape looks like it should hold face and edge info but isn't fully implemented yet. Its possible there is a subclass of it that i missed.

If someone is looking for code to compute the correct volume, center of mass, and inertia for a triangulated mesh then feel free to snag the code at
http://www.melax.com/volint.html
It should be a no brainer to rename the 3d vector types to fit within your own math library or the bullet types.

In some cases the center of mass and inertia calcs can be different than using a box approximation. The cone example mentioned earlier is one such case.