It occurred to me that FRotator doesn’t have a size.
When I want to know the difference between two rotators I subtract them and then add up the absolute value of their components individually (which is wrong but gives enough indication for my purposes with changes of only a few degress).
Is calculating the “size” or magnitude of a rotator not mathematically sound?
“Is calculating the “size” or magnitude of a rotator not mathematically sound?”
Not really, no. Especially given the vagaries of Eulers.
Consider:
- RotationA: (P: 180, Y: 180, R: 180)
- RotationB: (P: 0, Y: 0, R: 0)
According to your method, RotationA and RotationB have a difference in “size” of 540; but in reality they both have the exact same orientation.
Consider also:
- RotationA: (P:0, Y:0, R:90)
- RotationB: (P:90, Y:0, R:0)
According to your method, RotationA and RotationB have a difference in “size” of 0.
Finally, consider order of rotation. Imagine two objects with (0, 0, 0) rotation that begin facing forward.
- Rotate ObjectA along pitch: (90, 0, 0)
- Rotate ObjectA along roll: (90, 90, 0)
- Rotate ObjectB along roll: (0, 90, 0)
- Rotate ObjectB along pitch: (90, 90, 0)
According to your method, and just looking at the degrees, the difference in their “size” is 0; but ObjectA is now facing right, and ObjectB is facing up.
Factoring in gimbal lock, it’s even difficult to reliably determine the difference between two Euler sets along a single axis.
the plague of spherical statistics! i will look into this further, thanks!
You can convert the FRotator to an FQuat. That has ToAxisAndAngle() and AngularDistance() (for comparing two quaternions). I think the angle should be the best estimate of the ‘magnitude’ of the rotation – and quaternions don’t suffer from gimbal lock.