Hi everyone, I’m currently pulling my hairs off this issue, I’ve looked over various posts & websites, found some leads, but I had no luck in fixing my issue thus far.
The situation : I have a “ship” which has a Capsule Collider and a RigidBody (3D), that is supposed to move using AddForce to apply forward / backward thrust, and rotate using AddTorque around the Y axis ( The game is in 3D but technically moving on a 2D plane, so the two other axis are frozen ).
The principle is that you have a physical inventory, which is represented by cargo containers placed around the ship. These containers only have a collider, to detect on their own collision with, for exemple, asteroids and also to make a few calculations. They all are parents of “anchors” which are parents of the ship itself.
Up to this point, it works like a charm, until I realised a very odd behaviour.
The Problem : Once the whole ship has an uneven mass repartition ( if some cargo is lost ), the AddTorque ( I presume ) no longer respects the frozen rotation and start adding unwanted rotation on the X and Z axis.
if (InputManager.MovementAxis.x > 0)
ShipRigidbody.AddTorque(Torque * Vector3.up);
if (InputManager.MovementAxis.x < 0)
ShipRigidbody.AddTorque(-Torque * Vector3.up);```
I tried manually setting the center of mass, inertiaTensor and inertiaTensorRotation back to the Start value each time I change the mass repartition, but it still occurs.
Am I missing something ? Does anybody know what is causing this ? Or maybe the way i'm doing it is bad ?
I tried using things like Parent Constraints or Fixed Joints, but results where not satisfying.
Thanks a lot for your time & help !
PS : I'm on Unity 2022.1.
Rigidbody constraints seem not to be reliable since PhysX 3 (Unity 5). I can recall the rotation constraints being violated easily back then when first trying the upgrade.
Rigidbody rotations have been severely simplified since PhysX 3, to the point that they don’t even integrate the Euler equations. As a result, the rotation of Rigidbodies with non-uniform inertia is plainly unrealistic. As for my tests, the result of adding momentum via AddForce/AddTorque in these rigidbodies is highly questionable and doesn’t seem to correspond to a correct physics simulation as well. I wouldn’t be surprised if this also causes a direct conflict with rotation constraints.
Configuring inertiaTensor and inertiaTensorRotation once on Start to their own initial values (just assign their initial values to themselves) disables the automatic inertia recalculation. This allows to add/remove colliders without modifying the behavior of AddForce/AddTorque. How all this interacts with the rigidbody constraints is uncharted territory.
I’d consider using a different method to enforce the constraints, such as applying forces/torques to counteract any deviation from the expected position / rotation.
As you said, simply adding these at Start solved the problem, seems a little silly, but it does work, no more wrong rotations !
Also thanks you for you extra infos on PhysX and it flaws !
As for the used method, I thought about it, if the current one doesn’t do the job in the futur, I might look into it
Good to see that resolving it was a simple as that! It’s interesting to note that having a non-uniform inertia also violates the rotation constraints. In my case I had encountered the problem with the WheelCollider frequently applying unwanted rotations ignoring the constraint settings.
I was getting really frustrated with unwanted X, Z rotations when I have X, Z rotations frozen on my rigidbodies, and I’m only using AddTorque and AddForce, and all of my vectors only lie on the XZ plane. Shocked that this simple solution fixed it…
