fix(tracking): 🐛 Correct quaternion multiplication order in motion prediction

[zk-wz]

This PR corrects the multiplication order to old * delta, ensuring that the rotational delta from angular velocity is correctly applied in the local coordinate system rather than world coordinate system of the tracked device.

The wrong multiplication was made apparent after the motion prediction logic was moved from the client to the server in #2904 , which make the movement of the controller become strange under high-speed movement.

[zmerp]

OpenXR uses velocities in global coordinates. This is what we would like to adhere to. SteamVR instead uses local coordinate system. We are doing the conversion from global to local in TrackingManager::report_device_motions, this was never documented. So the fix I would like is to remove the conversion code from there and reapply it after prediction inside alvr_client_openvr. In the future we will also have a Monado target where no conversion will be needed (this will be handled by another crate or repo).

Sorry for not working on this before but I'm quite busy and I was unable to test. I'll leave this to you in the meantime, let me know how it goes.

[zk-wz]

Changes committed.

[zmerp]

There seems to be a mismatch, are you sure the linear velocity doesn't need changing?

[zk-wz]

The angular velocity here is in global coordinates, hasn’t been converted, it matches the global linear velocity, so I think it is no need to change.

[zmerp]

I suspect this needs some more thought. Both the recentering and the controller offset parameters would also shift the frame of reference for the linear and angular velocity. I think this wasn't correct before and still isn't correct now. But if it works good enough now i think i can merge

[zmerp]

If it works alright for you, we can merge

[zk-wz]

The problem seems to be in the prediction phase. Maybe we should perform the prediction first and then apply the offset, otherwise the controller rotation after applying the offset is not as expected.
I will try to fix it.

[zk-wz]

I messed it, this has nothing todo with predict, it should be an issue with the linear velocity processing. Let me check again.

[zk-wz]

need a new setting option to set the rotation center for controller and hand tracking, now I use the default offset value as alternative, requires refactoring

[zmerp]

Oh yeah. Well on the client side we do apply per-platform pose corrections for controllers. But we don't correct the origin of the linear and angular velocity. So that would have to be done on the client side first

[zk-wz]

I think everything is okay now, it can be merged

[zmerp]

I don't understand why you need a pivot offset. Isn't this something that should be inferred by the controller offset? Does this mean that SteamVR always needs a pivot offset even when the controller offset is 0,0,0 (either for translation or rotation)?

[zk-wz]

For some device, such as my Pico4, the controller pivot position in the default state is at the tail rather than at the center. Although this can be fixed by modifying the pose corrections in the client, I observed that only some devices have applied it, which may cause others to have incorrect pivot position issues. Adding a pivot offset allows users to manually correct this issue.

If you insist that it should be entirely determined by the controller offset, I will remove this setting.

[zk-wz]

Actually I dont think pivot has sth todo with controller offset, pivot is just a relative position of the controller.
Previous process of controller offset is wrong. We just need to offset the controller($Position_{new} = Position + Offset$), rather than rotate the controller around its original position($Position_{new} = Position + Orientation \cdot Offset$), I have already fixed it in my commit.

[zmerp]

I think i will experiment more myself. It's hard to agree with certainty until i test more