Expose the full inertia tensor to scripting

[aaronfranke]

This PR is a revival of #1114 and half of #945

Describe the project you are working on

I am working on the ability to represent complex physics objects in Godot.

Describe the problem or limitation you are having in your project

This chair cannot have its inertia properly described without access to the full 3x3 matrix inertia tensor (or changing the orientation). An object as simple as a chair does not seem like a niche use case to me, it seems very common.

Currently the only way for this object to have remotely close to the correct inertia would be to let Godot calculate a tensor, but this would not be very accurate if the collision shapes do not match up perfectly, and they would not be very precise if the chair's material was not uniformly dense.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

The proposal is to expose the inertia tensor to the user, so advanced users can set up their own custom inertia tensors to improve the accuracy of advanced physics simulations.

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

The engine's internal physics system already uses an inertia tensor matrix, but it's not exposed to the user.

I have a compiles-but-completely-broken branch here: https://github.com/aaronfranke/godot/tree/rigid-body-intertia-tensor-mass-dist maybe someone can figure out what's wrong.

Here is what it would look like in the inspector, a matrix for inertia instead of a vector:

EDIT: Actually, instead of the inertia tensor, I think it would be better to expose the inertia orientation as an Euler Vector3 or Quaternion. I think it's more intuitive to work with and also it aligns with the updated glTF physics specs.

If this enhancement will not be used often, can it be worked around with a few lines of script?

It will not be used very often, but it is important for the small percentage of users who want to put in the work to have accurate physics simulations. It can't be worked around, this is about exposing.

Is there a reason why this should be core and not an add-on in the asset library?

Physics is a core feature, and this is about exposing something in physics currently hidden from the user.

[aaronfranke]

An alternative implementation would be to expose an inertia orientation property (can be Euler angles or Quaternion) to rotate the Vector3 principle axis inertia to have different principle axes. EDIT: Actually, I prefer this, I think it's more intuitive to work with and also it aligns with the updated glTF physics specs.

Note that these 2 different formats are not trivial to interchange with each other, because the inertia tensor is NOT a rotation Basis. The inertia tensor is a symmetric matrix with only 6 unique numbers, the 3 principle axis inertia values and the 3 coupling values between the axes. Due to this being non-trivial to work with, it might be desired to implement both options, provide both orientation and tensor, which would be redundant properties.

[perococco]

I have the same issue, but I wanted to solve it in another way. I started the discussion #7600 and it has been closed since setting a custom inertia tensor solves the issue.

I have been told to add the detail of how I wanted to solve it to this issue for completeness:

So my idea was :

1. Add a Mass Mode with 2 choices

   1. Uniform (the default choice)
   2. Non Uniform

   In Uniform mode, we have the current behaviour of Godot and the field Mass is visible and editable. In Non Uniform the Mass is not editable (and "not visible" or "visible with filled with computed mass" ? )

2. On each collision shape and a field Mass.

3. On the core engine, the computation of the mass_properties must be updated in the case of the Non Uniform mode.

   1. The total mass must be computed
   2. The computation of center of mass and the inertia tensor must use the mass of the CollisionShape3D instead of its volume.

In the editor it will be something like in this video:

godot.mp4

[erikscott128]

I made a discussion post about this (#7909) in which I proposed that the off-diagonal elements of the inertia tensor be an additional Vector3 such that it represents the second half of a tensor in Voigt Form. This will prevent users from creating invalid (non-symmetric) inertia tensors and will not alter the current implementation (ie, the Vector3 representing the diagonal entries can remain).

For my intended use case (vehicle dynamics) computing and inputting the off-diagonal products of inertia is a preferred method over determining the rotation matrix required to transform to the principle axes. CAD applications are likely to be the source of this information for users, and most are happy to report the full inertia matrix. I believe solidworks will report the principle axes as well, but it appears that Fusion360 does not.