To convert a matrix from EasyAR to Unity, we have created two utility functions: Utility.Matrix44FToMatrix4x4 and Utility.SetMatrixOnTransform. With the later one, we can do right-handed-to-left-handed conversion and matrix decomposition at the same time.
Or if you like a simpler approach, suppose M is the 4x4 transform matrix from EasyAR, you can calculate a transform matrix M' in Unity coordinates by
(1 0 0 0) (1 0 0 0) ( m11 m12 -m13 m14)
M' = (0 1 0 0) M (0 1 0 0) = ( m21 m22 -m23 m24)
(0 0 -1 0) (0 0 -1 0) (-m31 -m32 m33 -m34)
(0 0 0 1) (0 0 0 1) ( m41 m42 -m43 m44)
(m11 m12 m13 m14)
M = (m21 m22 m23 m24)
(m31 m32 m33 m34)
(m41 m42 m43 m44)
Notice that Unity convert its coordinate system to right-handed by inverting the Z-axis in the View matrix, so their projection matrix maps points from a right-handed coordinate system to a right-handed coordinate system. https://docs.unity3d.com/ScriptReference/Camera-worldToCameraMatrix.html
There are some defects with the EasyAR 2.x transforms and projection matrices, such as returning matrices with a negative determinant.
There are also inconsistencies between the Unity and non-Unity APIs, which slow our iterations.
There are also problems with non-OpenGLES2 rendering APIs with Unity, which is not easy to support one by one.
To address the above problems, we have moved to a rendering-API-neutral model. All the APIs accept and return transforms between right-handed coordinate systems.
For the right-handedness, we have observed that nowadays most books and systems use right-handed coordinate systems, and Microsoft have shifted from left-handedness in Direct3D to right-handedness in WPF, XNA and Mixed Reality. As of Unity, we have found the inconsistency that it uses left-handed coordinate systems in the high level API but right-handed coordinate systems in the low level API. We suspect that Unity have been affected by Direct3D.
To mitigate problems with Unity, we have created the above utility functions.