Fix Transform3D basis to OpenVR HmdMatrix conversion in matrix_from_transform

[Raphiiko]

I ran into some weird behaviour while trying to rotate overlays. To me it seems like there's an issue in matrix_from_transform.

As far as I can tell, matrix_from_transform and transform_from_matrix are supposed to be opposites of each other. So if I pipe a matrix into transform_from_matrix, and then pull the result back through matrix_from_transform, I should end up with the same matrix I started with.

However, this currently isn't the case.

Showcase

Take this OpenVR matrix as a starting point:

A =
  [ 0.7071   0.3536   0.6124   1.0000 ]
  [ 0.0000   0.8660  -0.5000   2.0000 ]
  [-0.7071   0.3536   0.6124   3.0000 ]

Run it through transform_from_matrix to get a Godot transform, then run that transform through matrix_from_transform to get an OpenVR matrix back out. Call that result C. We expect C == A.

Currently, this is not the case. When we swap the indices i and j in matrix_from_transform, the problem is solved.

Why this hasn't surfaced before

The mismatch only changes the result when the 3×3 block being converted is non-symmetric. Every existing caller of matrix_from_transform in the repo happens to pass a value where this doesn't matter:

• demo/overlay_main.tscn uses the identity transform for absolute_position.
• Overlays tracked to a controller or HMD use tracked_device_relative_position with just an origin offset (no rotation).
• The common "rotate 180° to face the viewer" trick also happens to be a case where it doesn't matter.

[vilhalmer]

Your analysis makes sense to me, I have a workaround that I didn't realize was a workaround in my code currently. Thanks!

It would be nice to have some actual unit tests someday instead of just the demo, but there's so little code that can be tested without mocking openvr…

[beniwtv]

Ha! I was thinking there was something off all the time. I remember writing at least one of these functions originally with the overlay code, so might have been me 😅