applyTorque E2 and the engine world matrix mismatch

[Doliman100]

Describe the bug

Currently E2 uses a world matrix from the current tick, but the applyTorqueCenter engine function expects an input to be in the world space of the previous tick.

This happens, because LocalToWorldVector calls GetPositionMatrix to get the world matrix. But that function uses get_m_world_f_object_AT which returns an interpolation between q_world_f_core_last_psi and q_world_f_core_next_psi. The interpolation factor is a time between the current tick and the next tick. At the time of executing event tick(), this time is close to the end of the tick, so the result is close to q_world_f_core_next_psi. The exact factor I measured in single-player is 0.999989986, but in multi-player this probably may be 0.5 or anything else.

On the other hand, the ApplyTorqueCenter function calls async_rot_push_core_multiple_ws which uses get_m_world_f_core_PSI to get m_world_f_core_last_psi which equals to q_world_f_core_last_psi and absolutely different from q_world_f_core_next_psi.

So, the function LocalToWorldVector have to be replaced with something which uses q_world_f_core_last_psi instead of interpolated matrix.
As a workaround, I undo this conversion by wrapping the torque input value with ent:toLocalAxis() and applying my own conversion multiplying it by a matrix saved from the previous tick at the end of the event OldWorldMatrix = matrix(entity).

How to reproduce the bug

Here is a sample chip. Join single-player, spawn cube025x025x025, freeze it a few units above the ground and place this chip at any place on the ground. The object orientation will match the world space and it must start spinning around the global Z axis.
test_m_world_last_next.txt

Uncomment the following line to view a bad behavior.

E:applyTorque(AV * E:inertia() / (180 / _PI / 39.3701^2))

Object will be spinning around local X (global X) axis. This is a bad behavior, because we are applying torque to spin it only around local Z axis which matches the global Z axis vec(0, 0, 1000).

Then comment it back and uncomment the following line to view a good behavior.

E:applyTorque(E:toLocalAxis(OldWorldMatrix * (AV * E:inertia()) / (180 / _PI / 39.3701^2)))

E:toLocalAxis(...) is used to undo phys:LocalToWorldVector(...) applied internally, because it uses q_world_f_core_next_psi which we don't want.
OldWorldMatrix * (...) is an attempt to access m_world_f_core_last_psi matrix. It works fine in single-player, but worse in multi-player, since LocalToWorld returns an interpolated matrix and not pure q_world_f_core_next_psi.
Object will be spinning around the global Z axis, as expected.

[thegrb93]

I'd say this is a garrysmod-issue with LocalToWorldVector. The code

wire/lua/entities/gmod_wire_expression2/core/entity.lua

Lines 741 to 743 in db99507

	torque = phys:LocalToWorldVector( clamp(torque) )
	-- Convert rad*in^2 to deg*m^2
	phys:ApplyTorqueCenter( torque * (180 / math.pi / 39.3701^2) )

should not have ill-defined behavior like that.

[thegrb93]

You'll probably get better results if you multiply inertia correctly as well. https://github.com/thegrb93/MyStarfallScripts/blob/0c63870d8d8cecbe6f64e3fb857678ea7d42b51b/libs/CriticalPD.txt#L77

[Doliman100]

Interesting way of applying inertia. Why are you doing it this way? Where I can read more about such method?
I took my way directly from the engine. It just multiplies the local space vector element-wise by inv_rot_inertia. So, multiplying it by the opposite rot_inertia gives pure velocity.
The callstack looks this way if you want to read more: CPhysicsObject::ApplyTorqueCenter() -> IVP_Core::async_rot_push_core_multiple_ws() -> h.set_pairwise_mult(&angular_impulse_cs, get_inv_rot_inertia());

Just in case, I tested the old applyTorque implementation which was using two ApplyForceOffset calls #2451. It has the same issue.

[thegrb93]

I think the equation you're looking at is the tau = I*alpha equation, which yes that'll be a piecewise multiplication for calculating the acceleration in the local reference frame, but when you're scaling your input torque by some inertia factor about an axis in the world frame, you need the inertia-about-an-axis equation I believe. Otherwise your calculation will only work if your object is aligned on one of the axis of rotation.

I'd have to check and test again, but I'm pretty sure this yielded the best results.

[thegrb93]

In local reference frame, piecewise multiplication works (I think?). Forgot the e2 function uses local reference frame while my code was computing the inertia factor from world reference frame axis.