ARKit vs SceneKit coordinates

Question

I'm trying to understand the difference between the different element introduced in ArKit and their maybe equivalents in SceneKit:

• SCNNode.simdTransform vs SCNNode.transform. In ARKit, it seems that people use SCNNode.simdTransform instead of SCNNode.transform. How do they differ? simdTransform seems to use column major order, while transform (SCNMatrix4) is row major. How do I convert one to the other? Just transpose? I've the impression that the tracking doesn't work as well if I use transform instead of simdTransform. Is that expected or just an impression? If I set one property, what happens if I then set the other one?

• ARFrame.camera vs Scene.pointOfView: Looking at their transforms, they seem to be a bit different:

.

// ARFrame.camera.transform (matrix_float4x4)
-0.01 0.99  -0.11 0.02
-0.99 0.00  0.11  0.06
0.10  0.11  0.98  0.0
0.0   0.0   0.0   1.0

// sceneView.pointOfView.transform (SCNMatrix4)
// or sceneView.pointOfView.simdTransform^T (matrix_float4x4)
0.99  0     0.11   0
0.01  0.99  -0.12  0
-0.11 0.11  0.98   0
0.03  0.6   0.0    0.99

Are they the same minus one rotation?

Answer 1

Both SceneKit and ARKit include symbols defined as SIMD types. Since ARKit imports SceneKit, the SIMD symbols defined in SceneKit are accessible to both. SIMD types enable parallel computation, so using them can improve the performance of your app's update logic. As you've found, there isn't always a convenient way to convert between a SIMD type and its older SceneKit or Core Graphics equivalent, so you'll usually get cleaner code by consistently using SIMD where possible.

Updating any property that affects the transform of a node also updates its other transform properties. This goes for local and world coordinates as well.

The camera property of ARFrame describes the device's hardware camera, not the virtual camera used to render the scene. While I would expect a close correspondence, my guess is you're polling the ARCamera instance before the SCNCamera instance has been updated during the render loop. If you can, I recommend driving those updates from the appropriate delegate methods, since you'll know the relevant data is up to date.