Remove the `centerOfMass` property

[aaronfranke]

The draft spec README currently has this centerOfMass Vector3 value:

	Type	Description
centerOfMass	number[3]	Center of mass of the rigid body in local space.

However, I don't think that this is a helpful property.

• Without this property, changing the center of mass can be achieved by moving around the body's children such that the origin of the body is the center of mass.

• Not all physics engines support the center of mass being at a different place than the origin. This property's existence complicates the implementation in those physics engines for not much of a benefit.

• Technically it's also inconsistent to have a property for the offset of the body's center of mass, while colliders use the glTF node's transforms to be offset from the origin (to be clear, I 100% agree that colliders should use glTF nodes for offsets).

I propose that this property be removed, and instead asset creators will use the body's origin as the center of mass.

[eoineoineoin]

I strongly disagree here. By having an implicit center-of-mass (COM) at the origin of the body node, artists are forced to think about that (invisible) property in order to get the correct behaviour.

I believe that in order for the extension to be as easy-to-use as possible, the artist would ideally setup their bodies and colliders without having to worry about tweaking individual parameters and it's the responsibility of the physics engine to do the correct thing. Mass, inertia and COM can be derived from the colliders when it has not been specified[0] and physics engines will typically have some method to calculate these properties, as it's a requirement for simulation.

You'd never expect an artist to specify an inertia tensor for a body, so I don't see why the COM would be any different; but removing the COM property and inheriting it from the node makes it non-optional and forces an artist to think about it. I would prefer that we could use some node transform to specify the COM, the fact that a node also has an orientation seems to introduce some ambiguity about the meaning of the inertia tensor.

From a quick (informal, incomplete) survey of physics engines, the ability to specify COM as an offset in body space is reasonably common, and, as you've observed, if the physics engine you're using doesn't support such an offset, it's possible to emulate by applying an additional transform to the body and corrosponding inverse transform on the body's colliders.

PhysX:
    https://gameworksdocs.nvidia.com/PhysX/4.1/documentation/physxguide/Manual/RigidBodyDynamics.html#mass-properties
Chaos Physics:
    https://docs.unrealengine.com/4.26/en-US/InteractiveExperiences/Physics/PhysicsBodies/Reference/
Bullet:
    https://pybullet.org/Bullet/BulletFull/classbtRigidBody.html#adeaff2386513eeaaa138e0e3b3acca66
Jolt:
    https://github.com/jrouwe/JoltPhysics/blob/master/Jolt/Physics/Body/Body.h#L27
Newton Dynamics:
    http://newtondynamics.com/wiki/index.php/NewtonBodySetCentreOfMass
Open Dynamics Engine:
    https://ode.org/wiki/index.php/Manual#Rigid_bodies
Box2D:
    https://box2d.org/documentation/classb2_body.html#a60cc46fc46849b0d5e61a151b7c41269

[0] There are situations where that's not desirable, though, so you do want to be able to optionally override the COM. Consider a car; most of the mass is concentrated towards the engine, but if you were to derive the COM from the convex hull of the car, you'd get a different result because the car is in reality made from inhomogenous materials, which isn't in the representation of the collider.

[aaronfranke]

Mass, inertia and COM can be derived from the colliders when it has not been specified[0]

I see where the main issue is, there is a strong difference between "auto" and explicitly a position, even if that position was just the origin. So really, the center of mass in this MSFT physics draft spec is not a Vector3 with a default value of zero, it's a nullable Vector3. This makes the proposed spec even more complicated than I thought it was.

I don't know how valuable an "auto" feature is, technically that part alone could also be done with just a boolean, but I am concerned that such a feature would differ significantly between physics engines. What if the algorithm differs between implementations? And what if we specify that some colliders have dense physics materials, but some engines don't support that feature, then the automatically derived value could drastically differ between implementations, resulting in inconsistent behavior which is undesired. IMO, it would be better to always be explicit.

I believe that in order for the extension to be as easy-to-use as possible, the artist would ideally setup their bodies and colliders without having to worry about tweaking individual parameters

If needed, the glTF-exporting tool that an artist is using can offer to move around the child objects of a body to make the origin of the body be the same as that tool's center of mass calculation system. Boom, now we have a file following a standard that's easy to implement, consistent across implementations, and does not burden artists. It makes a lot more sense to put the burden of any kind of automatic calculation on the exporter, not the importer.

I strongly disagree here. By having an implicit center-of-mass (COM) at the origin of the body node, artists are forced to think about that (invisible) property in order to get the correct behaviour.

They have to think about the property regardless. The difference is where to put it. If it's explicit, then it's one of the values you have to adjust in a menu. If it's the object's origin, then it can be adjusted by moving the children of the body. Both approaches require worrying about a property, but having it be the object's origin is more intuitive, since it's a place already visible in a scene by selecting the body and looking at its transform gizmo. I don't like re-inventing the wheel when it's not necessary, glTF already provides us with nodes, which have positions, and I want to use this.

[aaronfranke]

Changed in OMI https://github.com/omigroup/gltf-extensions/pull/167